Why language is used

Language sets us apart from the animal kingdom. It portrays civilization. Language is obviously a vital tool to differentiate between animals and humans. Language shapes our thoughts and emotions, and determines our perception of reality. We use language to express our feelings to other humans.

 

It is a means of communicating our thoughts and ideas to others, orally or in writing. Either we express ourselves orally or in writing, language is the tool we use for this purpose. It forges friendship, solidarity, cultural ties and economic relationships. Without a language only silence exists, as we cannot communicate with others.

The purpose of language

The capability of humans to transfer concepts, ideas and notions through speech and writing is unparalleled in any other species. Unlike the call systems of other primates which are closed, human language is far more open, and gains variety in different situations.

 

The human language has the quality of displacement, using words to represent things and happenings that are not presently or locally occurring, but elsewhere or at a different time. Language is central to the communication between humans, as well as being central to the sense of identity that unites nations, cultures and ethnic groups.

 

The invention of writing systems at least 5,000 years ago allowed the preservation of language on material objects, and was a major step in cultural evolution. Language is closely attached to ritual and religion. The “science of linguistics” describes the structure of language and the relationship between languages.

Language

A language is a dynamic set of visual, audio, or tangible symbols of communication and the elements used to manipulate them. Language can also refer to the use of such systems as a general phenomenon. Language is considered to be an exclusive human mode of communication. Although animals make use of quite sophisticated communicative systems, none of these are known to make use of all of the properties that are used to define a language.

 

Languages live, die, move from place to place, and change with time. Any language that ceases to change or develop is categorized as a dead language. Conversely, any language that is a living language, that is, it is in a continuous state of change, is known as a modern language. There are approximately 6,000 different languages currently in use, including sign languages, and many thousands more that are considered extinct.

SOFTWARE REQUIREMENTS ANALYSIS

Software Requirements Analysis (SRA) encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders (beneficiaries or users). Systematic requirements analysis is also known as requirements engineering. It is generally referred to as requirements gathering, requirements capture, or requirements specification.

 

SRA is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

 

SRA FUNCTIONS

 

Requirements analysis includes the following functions:

 

Eliciting the Requirements

It is the process of communicating with customers and users to determine what their requirements are. It can also be called requirements gathering.

 

Analyzing the Requirements

Analyzing is determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory and then resolving these issues.

 

Recording the Requirements

Requirements may be documented or recorded in various forms, such as natural language documents, use cases and user stories or process specifications.

 

SRA PROCESS

 

1.   Stakeholder interviews

Stakeholder interviews are a common method used in requirement analysis. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.

 

2.   Joint Requirements Development Sessions

Joint Requirements Development Sessions are also called Requirement Workshops. Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator, wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A proficient Business Analyst should be present to document the discussion. Utilizing the skills of a trained facilitator to guide the discussion, frees the Business Analyst to focus on the requirements definition process.

 

3.   Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.

 

4.   Measurable goals

Establishing a small set of critical measured goals, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over. Stakeholders and developers can then formulate tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements.

 

5.   Prototypes

Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn’t yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.

 

Prototypes can be flat diagrams (referred to as ‘wire-frames’) or working applications using synthesized functionality. Wire-frames are made in a variety of graphic design documents, and often all colors are removed from the software design in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.

 

6.   Use cases

A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.

 

Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner. A use case focuses on describing how to achieve a single business goal or task.

 

7.   Software requirements specification

A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional or supplementary requirements. Non-functional requirements are requirements which impose constraints on the design or implementation such as performance requirements, quality standards, or design constraints.

 

8.   Stakeholder identification

A major new emphasis in the past was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include; Organizations that integrate or may integrate horizontally with the organization the analyst is designing the system for, any back office systems or organizations, senior management.

 

SRA ISSUES

 

Stakeholder issues

There are a number of ways users can inhibit requirements gathering. Some times users don’t understand what they want or users don’t have a clear idea of their requirements. Problems also rise when users won’t commit to a set of written requirements. At times users insist on new requirements after the cost and schedule have been fixed, which leads to complications. Often communication with users is slow. Users often do not participate in reviews or are incapable of doing so. Some users are not technically sound and hence they don’t understand the development process. Users don’t know about present technology, so they emphasize on outdated technologies. This may lead to the situation where user requirements keep changing even when system or product development has been started.

 

Engineer/developer issues

Problems are also caused by engineers and developers during requirements analysis. Technical personnel and end users may have different vocabularies. As a result, they may incorrectly consider they are in perfect compliance until product delivery. Engineers and developers may try to make the requirements fit on an existing system or model, rather than develop a system specific to the needs of the client. Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client’s needs properly.

 

ATTEMPTED SOLUTIONS

One attempted solution to communications problems has been to employ specialists in the business or system analysis.

 

Techniques like Prototyping, Unified Modeling Language (UML), Use cases, and Agile software development are also intended as solutions to problems encountered with previous methods.

 

A new class of application simulations or application definitions tools have also entered the market. These tools are designed to bridge the communication gap between business users and the IT organization and also to allow applications to be test marketed before any code is produced. These tools offer:

 

§  Electronic whiteboards to sketch application flows and test alternatives

§  Ability to capture business logic and data needs

§  Ability to generate high fidelity prototypes that closely imitate the final application

§  Interactivity

§  Capability to add contextual requirements and other comments

§  Ability for remote and distributed users to run and interact with the simulation

BUSINESS PARTNERSHIP

A partnership is a type of business entity in which partners/owners share with each other the profits or losses of the business undertaking in which all have invested. Partnerships are often favored over corporations for taxation purposes, as the partnership structure does not generally incur a tax on profits before it is distributed to the partners i.e. there is no dividend tax levied. However, depending on the partnership structure and the jurisdiction in which it operates, owners of a partnership may be exposed to greater personal liability than they would as shareholders of a corporation.

 

In partnerships there are two types of partners:

 

1.    General partners are those who have an obligation of strict liability to third parties incurred by the Partnership. General partners may have a joint liability or a joint and several liabilities depending upon circumstances. The liability of limited partners is limited to their investment in the partnership.

 

2.    A silent partner is one who still shares in the profits and losses of the business, but who is uninvolved in its management, and/or whose association with the business is not publicly known.

 

CIVIL LAW AND PARTNERSHIP

In civil law systems, a partnership is a nominate contract between individuals who, in a spirit of cooperation, agree to carry on an enterprise, contribute to it by combining property, knowledge or activities, and share its profit. Partners may have a partnership agreement or declaration of partnership and in some jurisdictions such agreements may be registered and available for public inspection. In many countries, a partnership is also considered to be a legal entity, although different legal systems reach different conclusions on this point.

 

COMMON LAW AND PARTNERSHIP

Under common law legal systems, the basic form of partnership is a general partnership, in which all partners manage the business and are personally liable for its debts. Two other forms which have developed in most countries are the limited partnership (LP), in which certain “limited partners” relinquish their ability to manage the business in exchange for limited liability for the partnership’s debts, and the limited liability partnership (LLP), in which all partners have some degree of limited liability.

 

i. GENERAL PARTNERSHIP

In the commercial and legal parlance of most countries a general partnership, or simply a partnership, refers to an association of persons or an unincorporated company with the following major features:

 

§  It is formed by two or more persons

§  The owners are all personally liable for any legal actions and debts the company may face

§  It is created by agreement, proof of existence and estoppels.

 

Characteristics

Partnerships have certain default characteristics relating to both (i) the relationship between the individual partners which can generally be overridden by agreement and (ii) the relationship between the partnership and the outside world which cannot be generally overridden by agreement.

 

The assets of the business are owned on behalf of the other partners, and they are each personally liable, jointly and severally, for business debts, taxes or tortuous liability. For example, if a partnership defaults on a payment to a creditor, the partners’ personal assets are subject to attachment and liquidation to pay the creditor.

 

By default, profits are shared equally amongst the partners. However, a partnership agreement will almost invariably expressly provide for the manner in which profits and losses are to be shared.

 

Each general partner is deemed the agent of the partnership. Therefore, if that partner is apparently carrying on partnership business, all general partners can be held liable for his dealings with third persons.

 

By default a partnership will terminate upon the death, disability, or even withdrawal of any one partner. However, most partnership agreements provide for these types of events, with the share of the departed partner usually being purchased by the remaining partners in the partnership.

 

By default, each general partner has an equal right to participate in the management and control of the business. Disagreements in the ordinary course of partnership business are decided by a majority of the partners, and disagreements of extraordinary matters and amendments to the partnership agreement require the consent of all partners. However, in a partnership of any size the partnership agreement will provide for certain electees to manage the partnership along the lines of a company board.

 

Unless otherwise provided in the partnership agreement, no one can become a member of the partnership without the consent of all partners, though a partner may assign his share of the profits and losses and right to receive distributions (”transferable interest”). A partner’s judgment creditor may obtain an order charging the partner’s “transferable interest” to satisfy a judgment.

 

ii. LIMITED PARTNERSHIP

A limited partnership is a form of partnership similar to a general partnership, except that in addition to one or more general partners (GPs), there are one or more limited partners (LPs).

 

iii. LIMITED LIABILITY PARTNERSHIP

A limited liability partnership (LLP) has elements of partnerships and corporations. In an LLP, all partners have a form of limited liability, similar to that of the shareholders of a corporation. However, unlike corporate shareholders, the partners have the right to manage the business directly.

 

ENDING A PARTNERSHIP

One disadvantage of partnerships is that when one partner wants to leave the company, the partnership generally dissolves. In that case, the partners must fulfill any remaining business obligations, pay off all debts, and divide any assets and profits among themselves.

 

To prevent this kind of ending for a business, a buy-sell agreement or buyout agreement should be shaped which can be included as part of the partnership agreement. A buy-sell/buyout agreement helps partners decide and plan for what will happen when one partner retires, dies, becomes disabled, or leaves the partnership to pursue other interests. For example, such an agreement might allow the partners to buy out a departing partner’s interest, so business can continue as usual.