Business Analyst

2009-08-31T15:42:00.000-07:00

2007-12-04T12:03:00.000-08:00

These questions are courtesy from a Business Analyst who went for an interview and were asked these questions.

1. Have you used customized version of Rational Unified Process?
2. If you are introduced to a new domain, how do you become familiar with it and start working on it?
3. What UML diagrams have you used in the past?
4. Give an example when you successfully acted as an interface between the technology team and the business areas?
5. What are your strengths as a business analyst?
6. What do you think is the most important responsibility of a business analyst.
7. Let us say you have created a class diagram for a given subject area. How do you make sure that you have captured all the methods/properties for a class and that you have capture all the classes.
8. What are your weaknesses?
9. Give an example of a situation when you managed conflict effectively.
10. What is a traceability matrix and how do you use it when using the Unified process?
11. What is your favorite mode of communication? Why?
12. What is your approach to resovling conflict during JAD sessions?
13. Let us say you in a JAD session and someone is constantly trying to divert the topic from what is on agenda for you to some peripheral item. How do you bring the session back on track?
14. What is the difference between Agile and Unified Process methodology?
15. Please tell something about yourself and your career background.
16. What makes you the best candidate for this position?
17. What are your strengths as a business analyst?
18. How would you handle a scenario when requirements change midway in the project?
19. What is your approach to solving problems?
20. What types of questions do you ask when gathering data for requirements?
21. How do you manage risk for a project?
22. What is your experience in project management?
23. Do you have any experience working with Enterprise configuration projects?
24. Why do you want to leave your current position?
25. Do you have any questions for us?
26. Who do you think are the main stakeholders for the project?
27. Describe the most challenging problem you have ever solved. What was your approach in doing so?
28. Describe a situation when you used some innovative technique for communicating ideas across? This was probably the best question and it really got me thinking.
29. What are your strengths as a business analyst?
30. How do you handle criticism of your work?
31. Have you used Use Cases/use case diagrams before and did you use any software for it?
32. Describe your ideal job.
33. Do you have any experience with Business Process Reengineering? Explain.
34. How do you go about working in an area with which you have not worked before?
35. How do you ensure that you have focused on all the necessary details of a task?

2006-09-26T11:55:00.001-07:00

Malik Prabu: Business Analyst

2006-09-14T14:11:00.000-07:00

Kaizen

Kaizen (Japanese for "change for the better" or "improvement", the English translation is "continuous improvement", or "continual improvement.") is an approach to productivity improvement originating in applications of the work of American experts such as Frederick Winslow Taylor, Frank Bunker Gilbreth, Walter Shewhart, and of the War Department's Training Within Industry program by Japanese manufacturers after World War II. The development of Kaizen went hand-in-hand with that of quality control circles, but it was not limited to quality assurance.

The goals of kaizen include the elimination of waste (defined as "activities that add cost but do not add value"), just-in-time delivery, production load leveling of amount and types, standardized work, paced moving lines, right-sized equipment, etc. A closer definition of the Japanese usage of Kaizen is "to take it apart and put back together in a better way." What is taken apart is usually a process, system, product, or service.

Kaizen is a daily activity whose purpose goes beyond improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates hard work (both mental and physical), and teaches people how to do rapid experiments using the scientific method and how to learn to see and eliminate waste in business processes.

"Kaizen" is the correct usage. "Kaizen event" or "kaizen blitz" are incorrect usage.
Kaizen is often misunderstood and applied incorrectly, resulting in bad outcomes including, for example, layoffs. This is called "kaiaku" - literally, "change for the worse." Layoffs are not the intent of kaizen. Instead, kaizen must be practiced in tandem with the "Respect for People" principle. Without "Respect for People," there can be no continuous improvement. Instead, the usual result is one-time gains that quickly fade.

Importantly, kaizen must operate with three principles in place: process and results (not results-only); systemic thinking (i.e. big picture, not solely the narrow view); and non-judgmental, non-blaming (because blaming is wasteful).

Everyone participates in kaizen; people of all levels in an organization, from the CEO on down, as well as external stakeholders if needed. The format for kaizen can be individual, suggestion system, small group, or large group.

The only way to truly understand the intent, meaning, and power of kaizen is through direct participation, many, many times.

History
After World War II, the occupational forces brought in American experts who were familiar with statistical control methods and with the War Department's Training Within Industry (TWI) training programs to restore a war-torn nation. TWI programs included Job Instruction (standard work) and Job Methods (process improvement). In conjunction with the Shewhart cycle taught by W. Edwards Deming, and other statistics-based methods taught by Joseph M. Juran, these became the basis of the kaizen revolution in Japan that took place in the 1950s.

Applications
The Toyota Production System is known for kaizen, where all line personnel are expected to stop their moving production line in the case of any abnormality, and suggestions for improvement are rewarded.
Kaizen often takes place one small step at a time, hence the English translation: "continuous improvement", or "continual improvement." Yet radical changes for the sake of goals, such as just in time and moving lines, also gain the full support of upper level management. Goals for kaizen workshops are intentionally set very high because there are countless examples of drastic reductions in process lead time to serve as proof of their practicality.
The cycle of kaizen activity can be defined as: standardize an operation -> measure the standardized operation (find cycle time and amount of in-process inventory) -> gauge measurements against requirements -> innovate to meet requirements and increase productivity -> standardize the new, improved operations -> continue cycle ad infinitum. This is also known as the Shewhart cycle, Deming cycle, or PDCA.

The "zen" in Kaizen emphasizes the learn-by-doing aspect of improving production. This philosophy is focused in a different direction from the "command-and-control" improvement programs of the mid-20th century. Kaizen methodology includes making changes and looking at the results, then adjusting. Large-scale preplanning and extensive project scheduling are replaced by smaller experiments in improvement, which can be rapidly adapted as new improvements are suggested.

Masaaki Imai made the term famous in his book, Kaizen: The Key to Japan's Competitive Success. An appendix to that book includes a reference to the 5S strategy of disciplined cleanup.

2006-09-06T10:45:00.000-07:00

Trials & Tribulations of a Business Systems Analyst

Click on the link above to read the entire article about being an analyst. There are some good articles in this page by H.M. Winning.

2006-09-05T13:22:00.000-07:00

Google Search:

Business analyst, business analyst jobs, business analyst interview questions, Malik Prabu, BA Jobs.

2006-08-22T16:04:00.000-07:00

Competitive Analysis

What: The Competitive Analysis is a tool to summarize and take inventory of what competitors are offering relative to your product/service/platform.

Why: The competitive analysis helps identify where you stand in the face of competition. You may learn that you have a best practice or competitive differentiator – or you may see best practices elsewhere that you may want to evaluate.

An in-depth analysis of your competitors is important to do periodically, depending on the level of change/innovation in your industry. It is important to stay abreast of changes and update your Fact Book.

Competitor Analysis

Who are your competitors?
Make a list of direct competitors in your space/ industry
Include any entity that has an impact on your target customer, look outside the financial services industry

Rank Competitors
From this list of competitors, rank them in terms of their influence on your target customer. Number them in terms of influence
To validate your analysis, ask yourself: Can I identify each competitor with a direct influence on my target market even if they aren’t doing it the same way I am? If you answer no, revise your list.

Analyze Competition
List your competitive set in order of influence on your target customer
Define the main categories that are most important to your target customer
Score yourself against your competitors
Analyze your competitors so you can define your competitive advantage

Product/ Service Differentiation

How do you differentiate your product/ service?
One effective way to do this is by clearly defining your product strategy. This will shape what you are and what you are not delivering in your product/ service.
The strategy will reflect:

1) The choice of products/ services you offers and the customers you seek to serve
Example: Should Ford introduce an updated model of the Barracuda or introduce a new set of models?

2) Competitive Differentiation. How you compete to attract, win, and retain customers.

Example: Nordstrom’s differentiates itself from the competition based on superior service and breadth of product selection in shoes.

3) The goals you pursue

Example: Should Apple try to be a major participant in every segment of the audio/ stereo industry or aim to be a leader in the small personal player segment?

On the next page, the major levers are identified to help you develop a product/ service strategy.

2006-08-22T12:53:00.000-07:00

Gap analysis

Gap analysis is a business assessment tool enabling a company to compare its actual performance with its potential performance. This provides the company with insight to areas which have room for improvement. The process involves determining, documenting and approving the variance between business requirements and current capabilities. Gap analysis naturally flows from benchmarking or other assessments. Once the general expectation of performance in the industry is understood then it is possible to compare that expectation with the level of performance at which the company currently functions. This comparison becomes the gap analysis. Such analysis can be performed at the strategic or operational level of an organization.

'Gap analysis' is a formal study of what a business is doing currently and where it wants to go in the future. It can be conducted in different perspectives as follows:
Organization (e.g. human resources)
Business direction
Business processes
Information technology

Gap analysis provides a foundation for how much effort, in terms of time, money and human resources, is required to have a particular aim achieved (e.g. to turn the salary payment process from paper based to paperless with the use of a system).

Gap Analysis and New Products

The need for totally new products or for additions to existing lines may have emerged from the portfolio analyses, in particular from the use of the Boston Growth Share Matrix. More probably, the need will have emerged from the regular process of following trends in the requirements of consumers. At some point a gap will have emerged between what the existing products offer the consumer and what the consumer demands. That gap has to be filled if the organization is to survive and grow.

To locate such a gap in the market the technique of gap analysis can be used. Thus an examination of what profits are forecast to be for the organization as a whole compared with where the organization (in particular its shareholders) 'wants' those profits to be represents what is called the planning gap: this shows what is needed of new activities in general and of new products in particular.

The planning gap may be divided into four main elements:

Usage Gap

This is the gap between the total potential for the market and the actual current usage by all the consumers in the market. Clearly two figures are needed for this calculation:
*market potential
*existing usage

Market potential

The most difficult estimate to make will probably be that of the total potential available to the whole market, including all segments covered by all competitive brands. It is often achieved by determining the maximum potential individual usage, and extrapolating this by the maximum number of potential consumers. This is inevitably a judgement rather than a scientific extrapolation, but some of the macro-forecasting techniques may assist in making this `guesstimate' more soundly based.
The maximum number of consumers available will usually be determined by market research, but it may sometimes be calculated from demographic data or government statistics. Ultimately there will, of course, be limitations on the number of consumers. For guidance one can look to the numbers using similar products. Alternatively, one can look to what has happened in other countries. It is often suggested that Europe follows patterns set in the USA, but after a time-lag of a decade or so. The increased affluence of all the major Western economies means that such a lag can now be much shorter.

The maximum potential individual usage, or at least the maximum attainable average usage (there will always be a spread of usage across a range of customers), will usually be determined from market research figures. It is important, however, to consider what lies behind such usage.

Existing usage

The existing usage by consumers makes up the total current market, from which market shares, for example, are calculated. It is usually derived from marketing research, most accurately from panel research such as that undertaken by A. C. Nielsen but also from 'ad hoc' work. Sometimes it may be available from figures collected by government departments or industry bodies; however, these are often based on categories which may make sense in bureaucratic terms but are less helpful in marketing terms.

The 'usage gap' is thus:

usage gap = market potential - existing usage

This is an important calculation to make. Many, if not most marketers, accept the 'existing' market size, suitably projected over the timescales of their forecasts, as the boundary for their expansion plans. Although this is often the most realistic assumption, it may sometimes impose an unnecessary limitation on their horizons. The original market for video-recorders was limited to the professional users who could afford the high prices involved. It was only after some time that the technology was extended to the mass market.

In the public sector, where the service providers usually enjoy a `monopoly', the usage gap will probably be the most important factor in the development of the activities. But persuading more `consumers' to take up family benefits, for example, will probably be more important to the relevant government department than opening more local offices.

The usage gap is most important for the brand leaders. If any of these has a significant share of the whole market, say in excess of 30 per cent, it may become worthwhile for the firm to invest in expanding the total market. The same option is not generally open to the minor players, although they may still be able to target profitably specific offerings as market extensions.
All other `gaps' relate to the difference between the organization's existing sales (its market share) and the total sales of the market as a whole. This difference is the share held by competitors. These `gaps' will, therefore, relate to competitive activity.

Distribution Gap

The second level of `gap' is that posed by the limits on the distribution of the product or service. If it is limited to certain geographical regions, as some draught beers are, it cannot expect to make sales in other regions. At the other end of the spectrum, the multinationals may take this to the extremes of globalization. Equally, if the product is limited to certain outlets, just as some categories of widely advertised drugs are limited by law to pharmacies, then other outlets will not be able to sell them. A more likely outcome is that, not being the market leader, a brand will find its overall percentage of distribution limited. The remedy for this is simply to maximize distribution.

Unfortunately, maximizing distribution is not quite as easy as it sounds, except for the obvious market leaders. It is true that additional salesforce effort, backed by suitable sales promotional activities, should be able to increase distribution somewhat, although there will still have to be some balance between the benefits to be gained and the costs to be incurred. But the prime barrier to distribution will probably be the resistance of the distribution chains to stock anything other than the bestsellers. This can partially be overcome in the short term by offering better terms and higher margins, so that the distributors make more on each sale. But the distributors have long since learned that their biggest profits come from concentrating on the main brands. They, above all, live by the 80:20 Rule.

Product Gap

The product gap, which could also be described as the segment or positioning gap, represents that part of the market from which the individual organization is excluded because of product or service characteristics. This may have come about because the market has been segmented and the organization does not have offerings in some segments, or it may be because the positioning of its offering effectively excludes it from certain groups of potential consumers, because there are competitive offerings much better placed in relation to these groups.

This segmentation may well be the result of deliberate policy. Segmentation and positioning are very powerful marketing techniques; but the trade-off, to be set against the improved focus, is that some parts of the market may effectively be put beyond reach. On the other hand, it may frequently be by default; the organization has not thought about its positioning, and has simply let its offerings drift to where they now are.

The product gap is probably the main element of the planning gap in which the organization can have a productive input; hence the emphasis on the importance of correct positioning.

Competitive Gap

What is left represents the gap resulting from the competitive performance. This competitive gap is the share of business achieved among similar products, sold in the same market segment, and with similar distribution patterns - or at least, in any comparison, after such effects have been discounted. Needless to say, it is not a factor in the case of the monopoly provision of services by the public sector.

The competitive gap represents the effects of factors such as price and promotion, both the absolute level and the effectiveness of its messages. It is what marketing is popularly supposed to be about.

Market Gap Analysis

In the type of analysis described above, gaps in the product range are looked for. Another perspective (essentially taking the `product gap' to its logical conclusion) is to look for gaps in the 'market' (in a variation on `product positioning', and using the multidimensional `mapping') which the company could profitably address, regardless of where its current products stand.
Many marketers would, indeed, question the worth of the theoretical gap analysis described earlier. Instead, they would immediately start proactively to pursue a search for a competitive advantage.

2006-08-22T11:34:00.000-07:00

What is SWOT analysis? What are the main aspects of SWOT analysis? How to write Good SWOT analysis of a company? Where to find information for SWOT analysis?

Introduction

Environmental opportunities are only potential opportunities unless the organization can utilize resources to take advantage of them and until the strategic leader decides that it is appropriate to pursue the opportunity. It is therefore important to evaluate environment opportunities in relation to the strengths and weaknesses of the organization’s resources, and in relation to the organization’s resources, and in relation to the organizational culture. Real opportunities exist when there is a close fit between environment, values and resources. An evaluation of an organization’s strengths and weaknesses in relation to environmental opportunities and threats is generally referred to as a SWOT analysis. The following report will look closely into the SWOT’s concept, its main aspects, and criteria for successful and effective SWOT analysis.

Main Aspects of SWOT Analysis

SWOT has a long history as a tool of strategic and marketing analysis. No one knows who first invented SWOT analysis. It has features in strategy textbooks since at least 1972 and can now be found in textbooks on marketing and any other business disciplines. It advocates say that it can be used to gauge the degree of “fit” between the organisation’s strategies and its environment, and to suggest ways in which the organisation can profit from strengths and opportunities and shield itself against weaknesses and threats (Adams, 2005). However, SWOT has come under criticism recently. Because it is so simple, both students and managers have a tendency to use it without a great deal of thought, so that the results are often useless. Another problem is that SWOT, having been conceived in simpler times, does not cope very well with some of the subtler aspects of modern strategic theory, such as trade-offs (De Witt and Meyer, 1998).

Strengths

Determine an organisation’s strong points. This should be from both internal and external customers. A strength is a “resource advantage relative to competitors and the needs of the markets a firm serves or expects to serve” (http://www.css.nccu.edu.tw/mepa/mepa_course/2005/kao/ 20060221_1.ppt#1). It is a distinctive competence when it gives the firm a comparative advantage in the marketplace. Strengths arise from the resources and competencies available to the firm.

Weaknesses

Determine an organisation’s weaknesses, not only from its point of view, but also more importantly, from customers. Although it may be difficult for an organisation to acknowledge its weaknesses it is best to handle the bitter reality without procrastination. A weakness is a “limitation or deficiency in one or more resources or competencies relative to competitors that impedes a firm’s effective performance” (http://gift.postech.ac.kr/admin/bbs/data/summer_session_2004/ Corporate%20Strategy_ver%5B7%5D_final(1).ppt).

Opportunities

Another major factor is to determine how organisations can continue to grow within the marketplace. After all, opportunities are everywhere, such as the changes in technology, government policy, social patterns, and so on. An opportunity is a major situation in a firm’s environment. Key trends are one source of opportunities. Identification of a previously overlooked market segment, changes in competitive or regulatory circumstances, technological changes, and improved buyer or supplier relationships could represent opportunities fro the firm.

Threats

No one likes to think about threats, but we still have to face them, despite the fact that they are external factors that are out of our control, for example, the recent economic slump in Asia. It is vital to be prepared and face threats even during turbulent times. A threat is a major unfavourable situation in a firm’s environment. Threats are key impediments to the firm’s current or desired position. The entrance of new competitors, slow market growth, increased bargaining power of key buyers or suppliers, technological changes, and new or revised regulations could represent threats to a firm’s success.

Because SWOT is such as familiar and comforting tool, many students use it at the start of their analysis. This is a mistake. In order to arrive at a proper SWOT appraisal, other analyses need to be carrier out first.

• Since opportunities and threats mostly arise from the environment, SWOT analysis needs to take account of the results of a full environmental analysis.

• It is impossible to gauge what an organisation’s real strengths are until you have assessed its strategic resources – in fact, strategic resources and strength are the same thing. There is a tendency for students to put down anything vaguely favourable that they can think of about a company as a strength. This temptation needs to be resisted - a strength is not a strength unless it makes a genuine difference to an organisation’s competitiveness. The same is true of weaknesses.

For example, look at Southwest Airlines and Amazon.com. Both companies have important groups of potential customers to whom they offer poor service. Southwest ignores business passengers, and will not accept transfers from other airlines. Amazon makes people wait days to receive books that they can obtain instantly from their neighbourhood bookstores, and pay a delivery charge for the privilege. Surely, these are major threats. Southwest and Amazon have chosen not to give those customers priority. Serving them would divert resources from the firm’s core markets, and dilute service to their main customers. Not serving them is certainly not a weakness; in a paradoxical way, it may be a strength.

The wizardry of SWOT is the matching of specific internal and external factors, which creates a strategic matrix and which makes sense. It is essential to note that the internal factors are within the control of organisation, such as operations, finance, marketing, and other areas. On the contrary, the external factors are out of the organisation’s control, such as political and economic factors, technology, competition, and other areas. The four combinations are called the maxi-maxi (strengths/opportunities), maxi-mini (strengths/threats), mini-maxi (weaknesses/opportunities), and mini-mini (weaknesses/threats). Weihrich (1982) describes the four combinations as follows:

1. Maxi-maxi (S/O). This combination shows the organisation’s strengths and opportunities. In essence, an organisation should strive to maximise its strengths to capitalise on new opportunities.

2. Maxi-mini (S/T). This combination shows the organisation’s strengths in consideration of threats, e.g. from competitors. In essence, an organisation should strive to use its strengths to parry or minimise threats.

3. Mini-maxi (W/O). This combination shows the organisation’s weaknesses in tandem with opportunities. It is an exertion to conquer the organisation’s weaknesses by making the most of any new opportunities.

4. Mini-mini (W/T). This combination shows the organisation’s weaknesses by comparison with the current external threats. This is most definitely defensive strategy, to minimise an organisation’s internal weaknesses and avoid external threats.

How to Write a Good SWOT Analysis

A successfully conducted SWOT involves identifying the following:

• The things an organisation does particularly well (strengths) or badly (weaknesses) at present; • The factors that in the future may give the organisation potential to grow and increase its profits (opportunities) or may make its position weaker (threats). Opportunities and threats normally arise from changes in the environment, but sometimes have their origin inside the organisation – for example, if key machinery or people, functioning very effectively at present, are likely to break down or retire in a few years’ time, that is a threat.

It is important to bear in mind what a SWOT is for. It is intended to summarise a strategic situation, with a view to deciding what the organisation should do next. A SWOT analysis should contain sufficient information for any reader to be able to see why a particular issue counts as a strength, weakness, opportunity or threat, and what the implications are for the firm that you are analysing.

For the same reason, there is no room for equivocation in a SWOT analysis – a factor can be a strength or a weakness, but not both. For example, a firm’s IT system may provide good management reports but poor production control information. It is pointless to put this down as both a strength and a weakness that partially cancel each other out, since manager have only two choices: either they upgrade the system or they do not (Mintzberg, 1990). This means that you need to come to definite answer to the question: On balance, is the IT system a strength or a weakness? Perhaps the lack of good production information is important, in which case the system needs to be upgraded. Perhaps it is vital to maintain the flow of management information, in which case the system should not be touched (Thompson, 2002). SWOT analysis aims to differentiate factors from being bad or good for the company’s performance. In a SWOT analysis, the strengths and weaknesses of resources must be considered in relative and not absolute terms. It is important to consider whether they are being managed effectively as well as efficiently. Resources, therefore, are not strong or weak purely because they exist or do not exist. Rather, their value depends on how they are being managed, controlled and used.

SWOT analyses should only pick out issues that have a substantial effect on a firm’s competitive situation. You should avoid the temptation to put down under “Strengths” almost everything you can think of that is vaguely favourable to the firm, and to classify anything remotely unfavourable as a weakness. It is rare for any firm should be rare, difficult to copy and make a genuine difference to the organisations’ profitability – a strategic resource. A weakness, similarly, is something that affects the organisation’s cost or differentiation advantage. Old-fashioned equipment and authoritarian management styles, for instance, are only weaknesses if they lead to increased costs, poor quality or bad customer service (Thompson, 2002; Adams, 2005).

Lists of strengths and weaknesses should not include factors that are common to every firm in an industry. For example, you could not count “well-known brand” as a strength for a firm in the jeans or cosmetic industries, since many brands are equally famous. Instead of writing that main opportunities of the company are overseas expansion and brand extension, it is crucial to replace it with a broader definition and explanation. The example of a more successful explanation could be: “Eastern European markets, with developing spending power and proven appetite for Western consumer brands, represent opportunity. 25% of existing sales in airport outlets are to customers travelling to these countries”. Another example could involve: “Competing firms have extended brands to cosmetics, spectacles, jeans and stationery. Likely opportunity for this firm to follow suit” (Adams, 2005).

Instead of saying that the threat of a firm is in exchange rate fluctuations, the statements of: “Appreciation of euro versus dollar likely to lead to reduce value of US profits (25% of total)” or “This is a specific threat that affects this firm because of its high proportion of US sales” could be appropriate (De Witt and Meyer, 1998).

In order to write a good SWOT the following criteria must be taken into account:

• Make your points long enough, and include enough detail, to make it plain why a particular factor is important, and why it can be considered as a strength, weakness, opportunity or threat. Include precise evidence, and cite figures, where possible;

• Be a specific as you can about the precise nature of a firm’s strength and weakness. Do not be content with general factors like economies of scale;

• Avoid vague, general opportunities and threats that could be put forward for just about any organisation under any circumstances;

• Do not mistake the outcomes of strength (such as profits and market share) for strengths in their won right;

• Improvements is not the same as strength – do not confuse the two;

• Avoid contradicting yourself in the course of the analysis, by having strengths and weaknesses that are essentially different aspects of the same strategy of resource. Come to a reasoned conclusion about whether the good points outweigh the bad ones, or vice versa.

Where to Find Information for SWOT Analysis

Students, when finding the essential information for conducting SWOT analysis, would have to look at company’s business reports, annual reviews, published performance data on financial resources, marketing and operations, including current suppliers and key stakeholders groups.

It can also be helpful to search various journals on marketing, strategy, human resources to find out more published and referenced information on the company’s past experience, its current position and future objectives.

SWOT Analysis Limitations

A key element of strategic option formulation is the matching of organizational strengths and weaknesses with opportunities and threats which exist in the marketplace. SWOT analysis is widely recognized in the marketing and strategic management literature as a systematic way of achieving this end. A number of critics however have claimed that the output from a SWOT analysis is often either trivial or so broad as to be relatively meaningless in the context of making actual marketing decisions. Mintzberg (1990), for example, states that the assessment of strengths and weaknesses may be unreliable, being bound up with aspirations, biases and hopes. Therefore, it is important for strengths and weaknesses to be defined in the context of a situation. As a consequence, a creative problem-solving tool such as brainstorming may thus be a useful help in overcoming this difficulty.

SWOT analysis can be used in many ways to aid strategic analysis. The most common way is to use it as a logical framework guiding systematic discussion of a firm’s resources and the basic alternatives that emerge from this resource-based view. What one manager sees as an opportunity, another may see as a potential threat. Likewise, a strength to one manager can be a weakness to another. Different assessments may reflect underlying power considerations within the firm or differing factual perspectives. Systematic analysis of these issues facilitates objectives internal analysis (Hill and Westbrook, 1997; Markides, 1999). Understanding the key opportunities and threats facing a firm helps its managers identify realistic options from which to choose an appropriate strategy and clarifies the most effective niche for the firm.

One of the historical deficiencies of SWOT analysis was the tendency to rely on a very general, categorical assessment of internal capabilities. The resource-based view came to exist in part as a remedy to this void in the strategic management field. It is an excellent way to identify internal strengths and weaknesses and use that information to enhance the quality of a SWOT analysis. Similarly, value chain analysis identifies elements of a company’s capabilities and operations that are useful in conducting a SWOT analysis.

Conclusion

SWOT helps a company to se itself for better and for worse. Companies are inherently insular and inward looking SWOTs are a means by which a company can better understand what it does very well and where its shortcomings are. SWOTs will help the company size up the competitive landscape and get some insight into the vagaries of the marketplace.

SWOT analysis has been a framework of choice among many managers for along time because of its simplicity and its portrayal of the essence of sound strategy formulation - matching a firm’s opportunities and threats wit its strengths and weaknesses. Central to making SWOT analysis effective is accurate internal analysis – the identification of specific strengths and weaknesses around which sound strategy can be built.

2006-08-22T11:02:00.000-07:00

Determine The Root Cause: 5 Whys

Asking "Why?" may be a favorite technique of your three year old child in driving you crazy, but it could teach you a valuable Six Sigma quality lesson. The 5 Whys is a technique used in the Analyze phase of the Six Sigma DMAIC methodology. It's a great Six Sigma tool that doesn't involve data segmentation, hypothesis testing, regression or other advanced statistical tools, and in many cases can be completed without a data collection plan.
By repeatedly asking the question "Why" (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. Very often the ostensible reason for a problem will lead you to another question. Although this technique is called "5 Whys," you may find that you will need to ask the question fewer or more times than five before you find the issue related to a problem.

Benefits Of The 5 Whys

 Help identify the root cause of a problem.
 Determine the relationship between different root causes of a problem.
 One of the simplest tools; easy to complete without statistical analysis.

When Is 5 Whys Most Useful?

 When problems involve human factors or interactions.
 In day-to-day business life; can be used within or without a Six Sigma project.

How To Complete The 5 Whys

1. Write down the specific problem. Writing the issue helps you formalize the problem and describe it completely. It also helps a team focus on the same problem.
2. Ask Why the problem happens and write the answer down below the problem.
3. If the answer you just provided doesn't identify the root cause of the problem that you wrote down in step 1, ask Why again and write that answer down.
4. Loop back to step 3 until the team is in agreement that the problem's root cause is identified. Again, this may take fewer or more times than five Whys.

5 Whys Examples

Problem Statement: Customers are unhappy because they are being shipped products that don't meet their specifications.
1. Why are customers being shipped bad products? - Because manufacturing built the products to a specification that is different from what the customer and the sales person agreed to.
2. Why did manufacturing build the products to a different specification than that of sales? - Because the sales person expedites work on the shop floor by calling the head of manufacturing directly to begin work. An error happened when the specifications were being communicated or written down.
3. Why does the sales person call the head of manufacturing directly to start work instead of following the procedure established in the company? - Because the "start work" form requires the sales director's approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office).
4. Why does the form contain an approval for the sales director? - Because the sales director needs to be continually updated on sales for discussions with the CEO.

In this case only four Whys were required to find out that a non-value added signature authority is helping to cause a process breakdown.

Let's take a look at a slightly more humorous example modified from Marc R.'s posting of 5 Whys in the iSixSigma Dictionary.

Problem Statement: You are on your way home from work and your car stops in the middle of the road.
1. Why did your car stop? - Because it ran out of gas.
2. Why did it run out of gas? - Because I didn't buy any gas on my way to work.
3. Why didn't you buy any gas this morning? - Because I didn't have any money.
4. Why didn't you have any money? - Because I lost it all last night in a poker game.
5. Why did you lose your money in last night's poker game? - Because I'm not very good at "bluffing" when I don't have a good hand.

As you can see, in both examples the final Why leads the team to a statement (root cause) that the team can take action upon. It is much quicker to come up with a system that keeps the sales director updated on recent sales or teach a person to "bluff" a hand than it is to try to directly solve the stated problems above without further investigation.

5 Whys And The Fishbone DiagramThe 5 Whys can be used individually or as a part of the fishbone (also known as the cause and effect or Ishikawa) diagram. The fishbone diagram helps you explore all potential or real causes that result in a single defect or failure. Once all inputs are established on the fishbone, you can use the 5 Whys technique to drill down to the root causes.

Take-Away Quotation"If you don't ask the right questions, you don't get the right answers. A question asked in the right way often points to its own answer. Asking questions is the ABC of diagnosis. Only the inquiring mind solves problems." -- Edward Hodnett

2006-08-21T16:46:00.000-07:00

My Favorite PowerPoint Resources

Of course, I am not the only one in our company who uses PowerPoint. Hardly. It has become ubiquitous in our organization. We use it for Board meetings, author presentations, sales conferences, and other ad hoc meetings. To misquote a verse from the Gospel of Matthew, “where ever two or three are gathered, there is PowerPoint in their midst.”
The problem is that most people using PowerPoint have not received adequate training. In fact, most have received no training whatsoever. As a result, too many people misuse the tool. This results in too many slides, too many bullets, and too much copy. Consequently, the tool often becomes a hindrance to communication rather than an aid.

Evidently, these people are not aware that the Web is full of PowerPoint resources. I contend that in less than two hours of surfing, you can radically improve the effectiveness of your PowerPoint presentations. Here is a list of resources to get you started (in alphabetical order):

Beyond Bullets—This is great Web site on how to use PowerPoint more effectively. The content is very stimulating—and will challenge your presuppositions. Guaranteed. This is not a collection of more templates and clipart. Instead, it presents serious thinking about the way you use PowerPoint and how to improve your effectiveness.

Crystal Graphics—This is a great source for PowerPoint add-ins that enhance the basic program. Television-like transitions, 3D Titles, supershapes, and custom templates are some of the more popular add-ins. I have purchased several of these and found the quality excellent. My only caution is that some of the effects, particularly the television-like transitions, require some serious hardware horsepower.

DesignSense—This company advertises itself as “graphic design training for businesspeople.” It contains a series of design lessons for people (like me!) who have no formal graphic design training. They claim that the training you receive on the site is equivalent to a 40-hour graphic design course. However, it is condensed into 12 hours of computer-based training. It costs $59.00.

Excelsius—This is my favorite charting program. It essentially creates animated flash movies, based on Excel data. It is highly customizable and very sophisticated. This also makes for a somewhat steep learning curve. However, if you want your charts to have the “wow” factor, no other charting program I have tried comes close.

MasterViews—This site is actually a blog. It offers a large collection of very specific and very practical PowerPoint tips. Comments from readers further enhance the value of the content. The site also offers news related to new PowerPoint add-ins and related hardware (like wireless pointers and mice).

Microsoft Clip Gallery Live—This is Microsoft’s clipart site. It is a good resource and it’s free. However, I prefer JupiterImages.com. It’s probably worth checking here first to see if you can find what you need. If you find that it just doesn’t have enough horsepower, then you can join JupiterImages.com or some other subscription site.

MindManager X5—This is one of the five most-used pieces of software on my computer. It will change forever the way you plan and prepare your presentations. It is essentially a brainstorming tool that allows you to create “mental maps” of your presentations. It will help you quickly get all your ideas out of your head and then organize them. In my experience, this tool provides a much faster path to the final result than any other tool I have ever used. When you are done with your map, you can export it directly to PowerPoint. Best of all, MindJet, the software developer, offers a free 30-day trial.

PowerPoint Add-Ins—This is a collection of mostly useful add-ins written by PowerPoint Guru, Shyam Pillai. My favorites are the “Handout Wizard for PowerPoint,” which allows you to create customized layouts, “Rename Shape/Slide Add-in,” which enables you to rename slides and shapes by clicking on them, and “Toolbox for PowerPoint,” which provides a collection of Shyam’s VBA code snippets for PowerPoint.

PowerPoint ImageObjects—This site offers a collection of what others call “floating objects.” These are graphic objects with transparent backgrounds that appear to float on top of the slide. The site offers collections of symbols and shapes, metaphor objects, numbers, bullets, and other objects. These objects are very cool and very professional.

PowerPoint Templates Pro—This is yet another collection of professionally produced PowerPoint templates. You can purchase single templates or a collection of templates. The site’s customers include a impressive roster of Fortune 100 companies.

PowerPointers—This site is not so much about PowerPoint as it is about planning, building, and delivering great presentations. It contains a series of very helpful articles, especially for people who are just getting started. Even veteran presenters will find plenty of helpful tips to improve the quality and impect of their presentations.

Presentation Plates—Yet another collection of PowerPoint templates. If you haven’t found what you are looking for, this site is worth checking.

PresentationPro—This site offers some very cool tools not found anywhere else. For example, EmailPRESENTER allows you to e-mail a PowerPoint presentation to someone within the body of the e-mail itself (rather than as an attachment). OnlinePRESENTER is similar, in that it allows your Web site visitors to run a PowerPoint presentation on your site without having to download the presentation and run it within PowerPoint itself.

Presenters Online—This site is sponsored by Epson. It contains a variety of helpful articles and resources related to PowerPoint software and presentation hardware. Naturally, the purpose of the site is to sell Epson hardware; however, I still found it useful.

Presenters University—This site is sponsored by InFocus, a competitor to Epson. It is one of the best siites for PowerPoint training. It contains a number of courses that you or your staff can work through. It has tons of articles, software you can download and try, and even an “Ask the Professor” bulletin board where you can get answers to your specific questions.

Projector Solution—This site has many resources. One article is must reading. It is called “The Art of Communicating Effectively: Tips about all aspects of pulling off a successful presentation!” It’s must reading for every PowerPoint presenter.
Really Bad PowerPoint—This is a controversial white paper written by Seth Godin, the author of The Big Red Fez, The Purple Cow, and Permission Marketing. You may not agree with Seth’s conclusions, sbut it will definitely stimulate your thinking. I distributed the article to my staff following a very tedious sales conference presentation. They read the article, made adjustments, and dramatically improved their presentation at the next sales conference. This article is great for squashing the tendency to make your slides too copy-intensive and bullet-heavy.

ZapIt Media—This is another collection of PowerPoint templates. But these are very different and very cool. Like PowerPoint Templates Pro, you can download single templates or collections.

AbsoluVision—This is a royalty free collection of images in the JPEG2000 format. (This is the new JPEG format that offers better quality at higher compression.) These are excellent images, many them depicted as floating objects. You can buy individual images for $4.95 each or subscribe to the service for $25.00 a month or $99.95 per year. Either option entitles you to download 200 images a month.

Indezine—This is a great PowerPoint information site run by Geetesh Bajaj, a Microsoft PowerPoint MVP. It contains PowerPoint articles, links, reviews, and templates. Geetesh also sends out a weekly ezine on PowerPoint. The reviews page is especially helpful. He lists almost every known PowerPoint add-in.

Tony’s PowerPoint Weblog—This blog bills itself as the Internet’s first business weblog dedicated to PowerPoint, presentations and related topics. It contains many short, insightful tips bound to improve your PowerPoint presentations.
If you have other resources that I have omitted, please use the comments feature on my site (see the end of this article) to share your favorites.

2006-07-28T15:12:00.000-07:00

Interview questions for a Business Analyst (With a large Internet search engine company):

• Can you go through your resume starting with your academics?
• If the end user doesn’t know what his specific requirements are or he has a big picture of requirements how you as a BA will drill down to the exact requirements.
• If I provided you with a workflow of events starting from kickoff of the project to UAT/training, explain me as a BA what role will you have in each phase and what timeline will you set for each phase?
• Have you dealt with difficult business users or How do you deal with difficult end users?
• What was your role in the last project / Explain me your last project.
• Have you worked with out-of-box solutions or implemented them?
• Do you have any exp. with document management systems?
• Was the end product in your last project a web based application or inhouse solution?
• How do you think you will gather requirement for our project?
• All your projects were year long, how will you deal with a fast paced project.
• Do you like projects on a short timeline?
• If there are multiple SMEs in a JAD session that disagree on a particular requirement how will you come to a closure?
• Sometimes JAD sessions can go on for hours together, how do you make sure that you control the sessions and achieve the desired result?
• How technically oriented are you?
• What’s your role with the development team?
• Explain to me what is in a FRD?
• What kind of domains have you worked on?
• Have you come across a situation where you didn’t meet the end users requirements and the UAT failed? How did you tackle the situation?
• Sometimes end user has a picture in mind of how the system/screen should look like but the end solution comes out to be different, how will you make sure that this doesn’t happen?

2006-07-27T19:40:00.000-07:00

Thank you note:

I think sending a small “thank you note” to the person who interviewed you is very effective method in many ways. Firstly, They (The client) are interviewing not only you but also 10 other Business Analyst for the same position. You want them to remember you over the other 10 they interviewed that day. The best way is to get their e-mail address after you are done with your interview and send them this short e-mail:

Dear Mr. Last Name:

I wanted to say "Thank You" for taking the time out of your busy schedule to talk to me about the Business Analyst position with Bank of America’s Internet Service Group. I appreciate your time and consideration in interviewing me for this position.

After speaking with you and the group, I do feel that I would be a perfect candidate for this position, offering the quick learning and adaptability that is needed for a diversified position.

In addition to my enthusiasm for performing well, I would bring the technical and analytical skills necessary to get the job done.

I am very interested in working for you and look forward to hearing from you once the final decisions are made regarding this position.

Please feel free to contact me at anytime if further information is needed. My cell phone number is (415) 555-1234

Thank you again for your time and consideration.

Sincerely,

Malik Prabu
Business Analyst
(415) 555-1234

2006-07-25T22:02:00.000-07:00

Requirement Gathering

Requirements analysis, in systems engineering and software engineering, encompasses all of the tasks that go into the instigation, scoping and definition of a new or altered system. Requirements analysis is an important part of the system design process; whereby requirements engineers, business analysts, along with systems engineers or software developers, identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.

In short Identifying the needs for a new project i.e. the main job of a BA or the most vital part of the whole deal is to gather the RIGHT requirements, thus it should be done with utmost care and precision. If there is a mistake in this process the end product may also end up screwed.

Different Types of requirements :

Feasiblitly
Schedulable
Affordable
Legality
Ethical issues

Requirement Gathering Techniques:

Interviews- Involves interviewing stakeholders and all the people involved, it may result in interviewing a lot of people but will help gather sound requirements and understand customer needs.

Requirement workshops - To bring the main stakeholders in the system together in order to analyse the system and develop the solution. These workshops are more properly termed Joint Requirements Development (JRD) sessions, where requirements are jointly identified and defined by stakeholders

Contract-style requirement lists - One way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of page, but it will provide a general checklist of requirements

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

Prototypes A.K.A. Mock up's
Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn't yet 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

Brainstorming - This involves identifying as many ideas as possible and ranking the ideas into those considered most useful by the group

Use Cases - This is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques

2006-07-25T14:08:00.000-07:00

Practical UML: A Hands-On Introduction for Developers

Note: This information was taken for reference/learning purpose only. Please visit the appropriate website to learn; just click on the above link.

The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML™, which stands for Unified Modeling Language™. The purpose of this course is to present important highlights of the UML.

At the center of the UML are its nine kinds of modeling diagrams, which we describe here.

Some of the sections of this course contain links to pages with more detailed information. And every section has short questions. Use them to test your understanding of the section topic.

Why is UML important?

Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.

Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.

The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model. A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes.

Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state.

Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity. Objects are instances of classes.

Use case diagrams

Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.

Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic.

"A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "

A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).

Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.

A use case diagram is a collection of actors, use cases, and their communications. We've put Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use case can have multiple actors.

Use case diagrams are helpful in three areas.

determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape.
communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.
generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Class diagrams

A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.

The class diagram below models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.

UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.

Our class diagram has three kinds of relationships.

association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.
aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails.
generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.

An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.

The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

Multiplicities	Meaning
0..1	zero or one instance. The notation n . . m indicates n to m instances.
0..* or *	no limit on the number of instances (including none).
1	exactly one instance
1..*	at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional items placed in a diagram to provide clarity.

Packages and object diagrams

To simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. The diagram below is a business model in which the classes are grouped into packages.

Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle. The dotted arrows are dependencies. One package depends on another if changes in the other could possibly force changes in the first.

Object diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.

This small class diagram shows that a university Department can contain lots of other Departments.

The object diagram below instantiates the class diagram, replacing it by a concrete example.

Each rectangle in the object diagram corresponds to a single instance. Instance names are underlined in UML diagrams. Class or instance names may be omitted from object diagrams as long as the diagram meaning is still clear.

Sequence diagrams

Class and object diagrams are static model views. Interaction diagrams are dynamic. They describe how objects collaborate.

A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.

Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window.

The Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message.

In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to make sure there is available room for each day of the stay in the hotel). The expression in square brackets, [ ], is a condition.

The diagram has a clarifying note, which is text inside a dog-eared rectangle. Notes can be put into any kind of UML diagram.

Collaboration diagrams

Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.

The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons ( : ).

Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

Statechart diagrams

Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state.

Our example diagram models the login part of an online banking system. Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation.

Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. From each state comes a complete set of transitions that determine the subsequent state.

States are rounded rectangles. Transitions are arrows from one state to another. Events or conditions that trigger transitions are written beside the arrows. Our diagram has two self-transition, one on Getting SSN and another on Getting PIN.

The initial state (black circle) is a dummy to start the action. Final states are also dummy states that terminate the action.

The action that occurs as a result of an event or condition is expressed in the form /action. While in its Validating state, the object does not wait for an outside event to trigger a transition. Instead, it performs an activity. The result of that activity determines its subsequent state.

Activity diagrams

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. A single transition comes out of each activity, connecting it to the next activity.

A transition may branch into two or more mutually exclusive transitions. Guard expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent merge marking the end of the branch appear in the diagram as hollow diamonds.

A transition may fork into two or more parallel activities. The fork and the subsequent join of the threads coming out of the fork appear in the diagram as solid bars.

Component and deployment diagrams

A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams show the physical configurations of software and hardware.

The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.

The physical hardware is made up of nodes. Each component belongs on a node. Components are shown as rectangles with two tabs at the upper left.

2006-07-24T18:44:00.000-07:00

More interview questions in .pdf format: Click Here

2006-07-24T18:42:00.000-07:00

Behavioral Interviewing Strategies for Job-Seekers

Note: All these interview questions are either taken from different websites or from personal experiences. All there appropriate references are given by their link. Click on each link to visit the resources.

Behavioral interviewing is a relatively new mode of job interviewing. Employers such as AT&T and Accenture (the former Andersen Consulting) have been using behavioral interviewing for about 15 years now, and because increasing numbers of employers are using behavior-based methods to screen job candidates, understanding how to excel in this interview environment is becoming a crucial job-hunting skill.

The premise behind behavioral interviewing is that the most accurate predictor of future performance is past performance in similar situations. Behavioral interviewing, in fact, is said to be 55 percent predictive of future on-the-job behavior, while traditional interviewing is only 10 percent predictive.

Behavioral-based interviewing is touted as providing a more objective set of facts to make employment decisions than other interviewing methods. Traditional interview questions ask you general questions such as “Tell me about yourself.” The process of behavioral interviewing is much more probing and works very differently.

In a traditional job-interview, you can usually get away with telling the interviewer what he or she wants to hear, even if you are fudging a bit on the truth. Even if you are asked situational questions that start out “How would you handle XYZ situation?” you have minimal accountability. How does the interviewer know, after all, if you would really react in a given situation the way you say you would? In a behavioral interview, however, it’s much more difficult to give responses that are untrue to your character. When you start to tell a behavioral story, the behavioral interviewer typically will pick it apart to try to get at the specific behavior(s). The interviewer will probe further for more depth or detail such as “What were you thinking at that point?” or “Tell me more about your meeting with that person,” or “Lead me through your decision process.” If you’ve told a story that’s anything but totally honest, your response will not hold up through the barrage of probing questions.

Employers use the behavioral interview technique to evaluate a candidate’s experiences and behaviors so they can determine the applicant’s potential for success. The interviewer identifies job-related experiences, behaviors, knowledge, skills and abilities that the company has decided are desirable in a particular position. For example, some of the characteristics that Accenture looks for include:

Critical thinking

Being a self-starter

Willingness to learn

Willingness to travel

Self-confidence

Teamwork

Professionalism

The employer then structures very pointed questions to elicit detailed responses aimed at determining if the candidate possesses the desired characteristics. Questions (often not even framed as a question) typically start out: "Tell about a time..." or "Describe a situation..." Many employers use a rating system to evaluate selected criteria during the interview.

As a candidate, you should be equipped to answer the questions thoroughly. Obviously, you can prepare better for this type of interview if you know which skills that the employer has predetermined to be necessary for the job you seek. Researching the company and talking to people who work there will enable you to zero in on the kinds of behaviors the company wants. (Click here to see a list of typical behaviors that employers might be trying to get at in a behavior-based interview.)

In the interview, your response needs to be specific and detailed. Candidates who tell the interviewer about particular situations that relate to each question will be far more effective and successful than those who respond in general terms.

Ideally, you should briefly describe the situation, what specific action you took to have an effect on the situation, and the positive result or outcome. Frame it in a three-step process, usually called a S-A-R, P-A-R, or S-T-A-R statement:

1. situation (or task, problem), 2. action, 3. result/outcome.

Click here for a sample S-A-R statement. It’s also helpful to think of your responses as stories. Become a great storyteller in your interviews, but be careful not to ramble. See also, STAR Interviewing Technique for more information.

It’s difficult to prepare for a behavior-based interview because of the huge number and variety of possible behavioral questions you might be asked. The best way to prepare is to arm yourself with a small arsenal of example stories that can be adapted to many behavioral questions. Despite the many possible behavioral questions, you can get some idea of what to expect by looking at Web sites that feature behavioral questions, including:

Sample Behavioral Interview Questions

Behavioral Interviewing

How to Behave in a Behavior-Based Interview

Knowing what kinds of questions might be asked will help you prepare an effective selection of examples.

Use examples from internships, classes and school projects, activities, team participation, community service, hobbies and work experience -- anything really -- as examples of your past behavior. In addition, you may use examples of special accomplishments, whether personal or professional, such as scoring the winning touchdown, being elected president of your Greek organization, winning a prize for your artwork, surfing a big wave, or raising money for charity. Wherever possible, quantify your results. Numbers always impress employers.

Remember that many behavioral questions try to get at how you responded to negative situations; you'll need to have examples of negative experiences ready, but try to choose negative experiences that you made the best of or -- better yet, those that had positive outcomes.

Here's a good way to prepare for behavior-based interviews:

Identify six to eight examples from your past experience where you demonstrated top behaviors and skills that employers typically seek. Think in terms of examples that will exploit your top selling points.

Half your examples should be totally positive, such as accomplishments or meeting goals.

The other half should be situations that started out negatively but either ended positively or you made the best of the outcome.

Vary your examples; don't take them all from just one area of your life.

Use fairly recent examples. If you're a college student, examples from high school may be too long ago. Accenture, in fact, specifies that candidates give examples of behaviors demonstrated within the last year.

Try to describe examples in story form and/or PAR/SAR/STAR.

To cram for a behavioral interview right before you're interviewed, review your resume. Seeing your achievements in print will jog your memory.

In the interview, listen carefully to each question, and pull an example out of your bag of tricks that provides an appropriate description of how you demonstrated the desired behavior. With practice, you can learn to tailor a relatively small set of examples to respond to a number of different behavioral questions.

Once you've snagged the job, keep a record of achievements and accomplishments so you'll be ready with more great examples the next time you go on a behavior interview.

Sample Behavioral Interview Questions

One of the keys to success in interviewing is practice, so we encourage you to take the time to work out answers to these questions using one of the suggested methods, such as the STAR approach. Be sure not to memorize answers; the key to interviewing success is simply being prepared for the questions and having a mental outline to follow in responding to each question. For more tips, read our article, Behavioral Interviewing Strategies.

Looking for some sample excellent answers to behavioral interview questions? Then go to our Job Interview Questions Database, where we have traditional, behavioral, and mixed interview questions for both experienced job-seekers and college students and recent grads.

Here is one list of sample behavioral-based interview questions:

Describe a situation in which you were able to use persuasion to successfully convince someone to see things your way.

Describe a time when you were faced with a stressful situation that demonstrated your coping skills.

Give me a specific example of a time when you used good judgment and logic in solving a problem.

Give me an example of a time when you set a goal and were able to meet or achieve it.

Tell me about a time when you had to use your presentation skills to influence someone's opinion.

Give me a specific example of a time when you had to conform to a policy with which you did not agree.

Please discuss an important written document you were required to complete.

Tell me about a time when you had to go above and beyond the call of duty in order to get a job done.

Tell me about a time when you had too many things to do and you were required to prioritize your tasks.

Give me an example of a time when you had to make a split second decision.

What is your typical way of dealing with conflict? Give me an example.

Tell me about a time you were able to successfully deal with another person even when that individual may not have personally liked you (or vice versa).

Tell me about a difficult decision you've made in the last year.

Give me an example of a time when something you tried to accomplish and failed.

Give me an example of when you showed initiative and took the lead.

Tell me about a recent situation in which you had to deal with a very upset customer or co-worker.

Give me an example of a time when you motivated others.

Tell me about a time when you delegated a project effectively.

Give me an example of a time when you used your fact-finding skills to solve a problem.

Tell me about a time when you missed an obvious solution to a problem.

Describe a time when you anticipated potential problems and developed preventive measures.

Tell me about a time when you were forced to make an unpopular decision.

Please tell me about a time you had to fire a friend.

Describe a time when you set your sights too high (or too low).

2006-07-24T18:41:00.000-07:00

Common Interview Questions: Click Here

Q: Tell me about yourself.
(The interviewer is really saying "I want to hear you talk")
A: This is a commonly asked question designed to break the ice. Spend a maximum of five minutes to describe your qualifications, career history and your range of skills. Emphasise those skills that are relevant to the job on offer.

Q: What have been your achievements to date?
(The interviewer is saying, "Are you an achiever?")
A: Again this is a common question so be prepared. Select an achievement that is recent. Identify skills you used in the achievement and quantify the benefit.

Q: Are you happy with your career to date?
(The interviewer is really asking about your self-confidence, your career aspirations and whether you are a positive person)
A: The answer must be 'yes' but if you have hit a career plateau or you feel you are moving too slowly, then you must qualify the answer.

Q: Tell me the most difficult situation you have had to face and how you tackled it? (The interviewer is really trying to find out your definition of "difficult" and whether you can show a logical approach to problem solving)
A: Select a difficult work situation that was not caused by you. Explain how you defined the problem and what solution you applied to overcome the problem.

Q: What do you dislike about your current role?
(The interviewer is trying to find out whether the job on offer has responsibilities you will dislike)
A: Be careful with this one. Don't be too specific as you may draw attention to weaknesses. One approach is to choose a characteristic of your present company such as its size, its slow decision making process etc. Give your answer with the air of someone who takes problems and frustrations in your stride, as part of the job.

Q: What are your strengths?
(The interviewer wants a straightforward answer as to what you are good at and how it is going to add value)
A: This is one question you will certainly be asked, so there's no excuse for being unprepared. Concentrate on discussing your main strengths. List three or four explanations of how they could benefit the employer. Strengths to consider include technical proficiency; ability to learn quickly; determination to succeed; positive attitude; team focus and your ability to work autonomously.

Q: What are your greatest weaknesses?
(The interviewer is asking about your self-perception and self-awareness)
A: This is another standard question for which you can be well prepared. Don't say you don't have any. We all have weaknesses. Either use a professional weakness such as a lack of experience (not ability) on your part in one area that is not vital for the job, or use a personal weakness and show the steps that you have taken to combat it. An example would be," I'm not very good at delegating but I'm learning to pass work on to colleagues by sitting down on a weekly basis and splitting the workload".

Q: What kind of decision do you find most difficult?
(The interviewer is really saying, "I need someone who is strong and decisive but who has a human side")
A: Try to focus on decisions you have made without sufficient information. This will show your positive side. For example, "I like to make decisions based on sufficient information and having alternatives. When you have to make quick decisions you have to rely on "gut feeling" and experience.

Q: Why do you want to leave your current employer?
(The interviewer is trying to understand and evaluate your motives for moving)
A: This should be straightforward. State how you are looking for more challenge, responsibility, experience and a change of environment and explain why you feel you are no longer receiving these things from your current role. For example, " I have been with my company for four years and feel I have learnt as much about their x function as possible and there is no opportunity for a more senior role at present".

2006-07-24T18:40:00.000-07:00

Business Analyst Interview Questions for the Banking Domain: Click Here

Handy if applying for business analyst intern positions. These questions are more of behavioral, so very good for the first round and for the behavioral interview of the second round.

My key observations for internship interviews at investment banks can be summarized as follows:

• Investment banks look for team work spirit and enthusiasm in the interns more than any technical skills.
• These questions, when read, look pretty easy and it always appears that you don't need to prepare for them. (which ofcourse is not true)
• Since these questions have no set answers, whatever you says directs what question will be asked next.
• If you have thought of the event to mention then you just need to concentrate on framing it elegantly.
• If you prepared for these beforehand, you never come out of the room regretting that you had a better example to quote if had been given more time to think.
• Sample space of such questions is exhaustive though the same question may be framed in many ways.

No one can have the questions that will be asked before hand but preparing for questions like these below helps in framing the answer well at interview as we already have in mind what we want to say. Remember, the worst one can do in an interview is to come for it unprepared.

Tip: Something I found very helpful in my interviews was that, while answering questions, I tried to use the same phrases and words as mentioned in the requirements of the job in the job description. You may call it a psychological treatment but it tends to indicate that you have exactly what they want. And I got calls from companies wherever I used it so I have evidence that it works!! :)

1- What's is the hardest thing you have ever done?

2- Can u give an example of a time when u came up with a creative solution?

3- Why do u want to work for this industry?
Very specific; based on what company one is interviewing with. This gives the candidate an opportunity to show why is he interested in this company above all others in the same industry. It reflects how much research did the candidate do on the company before coming here and that is an indicator good enough to measure his interest.

4- Why do you want to work in investment banking?
This was asked in all the interviews I gave till date. They wanted to know why one would prefer working for an investment bank and not a completely "tech" firm. I guess they expect the candidate to have some interest in finance even if he is going to the technical end though they don't expect any formal course work or previous experience in finance.

5- What exactly do investment managers do?

6- Present a chapter from your favorite finance book.
This looks like a tough birdie

7- Walk me through your resume?
Two of my interviews started with this question. They don't expect us to memorize our resumes but give us an opportunity to highlight the points of the resume we want to and choose the tentative topics for further questions. Effectively they say, "the ball is in your court".

8-Why should we hire u?
An indirect question that asks your strengths directly.

9-what types of activities where you involved in college?

10- Why this firm?
Same as question 3 above.

11- An example of a project that involved heavy analytical thinking?

12- If made CEO what changes will u make?

13- Favorite website?

14- Example of teamwork where the team was successful. One example where the team was unsuccessful. Why? What lesson did you learn from it.
Two of my behavioral interviews were centered most of the time around this question. I was first asked to go through the objective of the team and then how it worked or how didn't work right.

15- The most striking article in wall street journal

16- Project you enjoyed most.
Again they are asking you " From where do you want to me to ask the next question". Make sure you mention a project through which illustrates teamwork, self-initiative or something that you can stress upon later because after this the next question will be why did u enjoy this one most. And for investment banks , jut saying that you liked it because of the extensive coding it required won't get you anywhere. It is indirectly measuring that you really meant the reasons you gave for Question 4 or not.

17- Given internship, if not hired finally, give 3 reasons why this could happen and how can u prevent this.

18- If I call a person who knows you well, what will he say about you?

19- What motivates you?

20- An example of experience of failure.

21- You don't seem like a driven person. how will you handle a job in banking?

22- An accomplishment you are proud of?

23- Favorite course, least favorite. Why? Grades in each.

24- How have you modeled qith equations in the past.

25- Can you tell me a time when u handled many things at the same time?

26- Example of leadership. (Any academic or non-academic examples are equally good)

27- Example where you were not the leader of the team but you took some major initiative?

28- Questions for the firm.
This is a very important part of the interview and usually has the last 5 minutes devoted to it. The person on the other side of the table always give you a chance to ask questions partly to clear your doubts and partly to again give you an opportunity to show your interest and zest for internship in the company. Preparing for this merely requires 15-20 minutes reading the profile of the company and the dept. you are applying to.

2006-07-24T18:38:00.000-07:00

More Business Analyst Interview Questions:

Note: All these interview questions are either taken from different websites or from personal experiences. All there appropriate references are given by their link. Click on each link to visit the resources.

Few points to do and expect.

1.) You can ask the interviewer the content of the interview, ask them if you need to prepare anything for the interview?; what is the interview process?; how long will it be?, etc... the interviewer will give you some details but not all the details, they will propably tell you it's a one-on-one interview or it's a group exercise, depending on which round of interview you in.

2.) If it's the first round interview, it nothing hectic, if you ask them what's it about? They will say, this interview is for us (the company) to know you better and also give you an opportunity to know the company. So go to their website, look at their brochure, know the company information.

Prepare for:
• Why would you like to join our company?
• Where do you see yourself in 5 or 10 years time?
• What can you offer to the company? Skills, personality, etc....
• You areas of interest, why are you interested in finance, etc....
• Very important, I think, also prepare some questions to ask the interviewer, this shows that you are enthusiastic and keen for the job.

3.) Second round interviews, probably some kind of group exercise where the group get given a case study and need to work through the case study and discuss the solution. This is to see how well you do in a group environment, or it could be just a one person case study. Again you can ask the interviewer the content of the interview to be more prepared.

Prepare for:
• If it's really a group exercise, try take the leading role, if that fails, try take the secondary role, if all that fails, at least show that you are active in the discussion and enthusiastic about the discussion, etc....
• Nothing else you can really prepare for really, comes with experience.....

Round 3, 4, 5 again different content, could be contract negotiation, etc..... Know how to negotiate your paycheck!

Business analyst interview questions: Click Here

You never know what you will be asked on a job interview. The following sample of interview questions for business analyst will help you prepare. You need to be able to answer all questions truthfully and professionally. Here are the business analyst interview questions:

Q. Can you tell me why are you considering leaving your present job?
A. Regardless of the reason, do not bad mouth your current employer. Negativism will always hurt you. Good answers include: “There is no room for growth at my current employer. I am looking for a company with long term growth opportunities”. “Due to a company restructuring, my entire department is relocating to Florida. I was give the option of moving, but do not wish to relocate”. “My current company is not doing well, and has been laying off employees. There is no job security there, and more layoffs are expected”.

Q. How do you handle stress and pressure?
A. “I find that I work better under pressure, and I enjoy working in an environment that is challenging.” “I am the type of person that diffuses stress. I am used to working in a demanding environment with deadlines, and enjoy the challenges.”

Q. We have met several business analyst’s. Why are you the one we should hire?
A. Give definite examples of your skills and accomplishments. Be positive, and emphasize how your background matches the job description. Mention any software packages and spreadsheet software you are familiar with. Also let them know if you have advanced knowledge of any of the software.

Q. What do you know about our company?
A. This question is used to see if you have prepared for the interview. Candidates that have researched the company are more appealing. Companies like prepared, organized candidates.

Q. What are your greatest strengths?
A. Be positive and honest. “My greatest strength is maximizing the efficiency of my staff. I have successfully lead numerous teams on difficult projects. I have an excellent ability to identify and maximize each of my staffs strengths.” Give examples.

Q. Tell me about your greatest weakness?
A. It is very important to give a strength that compensates for your weakness. Make your weakness into a positive. “I consider myself a 'big picture' person. I sometimes skip the small details. For this reason, I always have someone on my team that is very detail oriented.” Another good answer: “Sometimes, I get so excited and caught up in my work that I forget that my family life should be my number one priority.”

Q. What are your goals for the future?
A. “My long term goals are to find a company where I can grow, continue to learn, take on increasing responsibilities, and be a positive contributor”.

Hopefully these typical business analyst interview questions will help you. It is important to customize the answers for your specific background and experience.

Now that we have gone over the interview questions for business analyst, you need to be aware of important resources that can make your job search easier and more thorough.

2006-07-24T18:37:00.000-07:00

Business analyst interview questions: Click Here

2006-07-24T18:35:00.000-07:00

One-on-one interview for a Business Analyst Position with the Project Director for an Insurance Company:

• The Project director explained the job initially and then she went over my resume.
• She had highlighted bullets from my resume and started asking how did you do this, how did you do that.
• Most of it was general BA stuff, with reference to the project I had done.
• How did you use RUP framework to implement change?
• Did you ever have to complain to the higher management because somebody wasn't co-operating to give out info?
• How do you get information, when people are not willing?
• What if there is no one to hold your hand and let you know what your job is?
• How do you figure out what you job is?
• Did you quit any of your previous jobs?
• Will you quit if you don't have enough direction?
• How do you design the process?
• What was the change that you handled from any of your jobs? and how did you do it?

2006-07-24T18:33:00.000-07:00

Detailed Change Control Procedure

Note: This material is copied from http://www.construx.com/survivalguide/detailedchangeproc.htm

Top-Level Contents

Revision Chart
Contents

1. Life Cycles of Work Products

2. Goals of a Change Control Procedure

3. Formative Development

4. Acceptance

5. Proposing Changes

6. Assessing Impact of Changes

7. Approving or Rejecting Proposed Changes

8. Change Control Board

9. Defect Tracking System

10. Approval Signatures

Detailed Contents

Revision Chart

This chart contains a history of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created.

The first time an organization adopts a change control procedure, the review cycles listed below might all be needed. After the change control procedure has been in place for awhile, each new project can probably just reference an existing change control procedure document, or a document with minor modifications, rather than creating its own.

Version	Primary Author(s)	Description of Version	Date Completed
Draft	TBD	Initial draft created for distribution and review comments	TBD
Preliminary	TBD	Second draft incorporating initial review comments, distributed for final review	TBD
Final	TBD	First complete draft, which is placed under change control	TBD
Revision 1	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD
Revision 2	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD
etc.	TBD	TBD	TBD

List the document contents by page number

List of Figures

List the figures in the document by page number.

Life Cycles of Work Products

Within any given project, each work product developed during the project will progress through a series of stages from initial concept to final release.

Work product lifecycle.

Note that the work product initially begins life in a state of formative development. As the work product develops, changes are made informally and work progresses using revision control. When the work product reaches an expected state of completeness, it undergoes formal review and acceptance. Once accepted, the work product enters a state of acceptance where changes are no longer permitted to the item without formal change control (which this document describes). Finally, after final acceptance, the work product is frozen in preparation for being released.

Note the distinction being made between informal revision control and formal change control. Informal revision control refers to the use of tools which allow changes to a rapidly evolving work product to be sequentially captured and retraced, if necessary. This allows a work product to undergo rapid development while retaining the safety of backup copies and some measure of control. Formal change control refers to a procedure by which changes to an accepted work product are carefully proposed, assessed, conditionally accepted, and applied. Formal change control provides a measure of stability and safety beyond that of the underlying revision control tools in use.

Goals of a Change Control Procedure

An effective change control procedure should:

Provide a mechanism for accepting changes that improve the product overall while rejecting those that degrade it.
Facilitate changes to work products during their initial formative development while avoiding unnecessary overhead or formality.
Provide revision control and backup safety for work products during their formative development.
Allow for formal acceptance (approval) of work products after their initial formative development has been completed.
Facilitate efficient changes to work products after their initial acceptance, recognizing that the impact of a change to a work product is dramatically different after the work product has been accepted.
Allow all parties materially affected by proposed changes to accepted work products to assess the resource, schedule, and/or product impact of the changes.
Allow changes to accepted work products to be proposed and evaluated, schedule and quality impact assessed, and approved or rejected into work products in a controlled manner.
Notify interested parties on the periphery of development regarding change proposals, their assessed impact, and whether the changes were approved or rejected.
Provide an historic trail of the development of work products, including all proposed changes.

Formative Development

During this initial stage of creation, the work product is undergoing frequent and rapid change before it becomes stable. At this stage, it is inappropriate to apply formal change control to the work product since the overhead of controlling changes merely obstructs efficient creation of the work product. However, this stage of development may comprise a significant body of work which would be quite costly to lose. Therefore, an informal determination will be made on the part of the developer(s) of the work product as to when to place the work product under revision control. Revision control differs from change control in that it provides automated support for saving and restoring versions of project work products such as documents and computer source code without the burden of a formal change process.

We expect the following procedures to provide adequate control during formative development of work products:

Work products will be placed under the control of a revision control tool (such as PVCS, RCS, or Visual Source Safe).
All work products under revision control will reside on a master project file server (which itself is under a formal backup schedule to secondary off-line media).

Since change control at this stage of development is informal, it is the responsibility of each developer to use prudent judgment and professional practice to store revisions of the work product at appropriate intervals and to be diligent in maintaining master sources of the work product on the project file server.

Acceptance

At the close of formative development, each work product reaches a stage where it represents a complete body of work. The determination of this point in the development process is best performed by the developer(s) of the work product (guided by the project milestones and deliverables identified by the Software Development Plan). At this point, the work product undergoes a formal acceptance procedure which includes:

Review of the work product content to determine whether it is complete and fairly represents the needs of its customers. (The determination of who will review each work product is made by the Change Control Board.)
Formal sign-off of the work product by the Change Control Board and any additional persons which the board determines are appropriate.

At this point, the work product is said to have been "accepted" (thereafter known as an accepted work product) and enters into formal change control. That is, subsequent changes to the work product must undergo review by the Change Control Board as described below.

Proposing Changes

Whenever any party determines that some aspect of an accepted work product should be changed, then that party submits a change proposal to the Change Control Board via the defect tracking system. The change proposal:

Identifies the work product in question.
Describes the aspect of the work product that the party feels is in need of change.
Includes a description of the impact, from the submitting party's point of view, of leaving the work product as-is compared with incorporating the suggested change. This gives the Change Control Board a better understanding of why the change is being submitted and what importance it has from the perspective of the submitting party.

Assessing Impact of Changes

Once a change proposal has been submitted to the Change Control Board, the change proposal is circulated to those parties that the Change Control Board identifies may be impacted by the change. These parties are responsible for producing an estimate of the effects of implementing the proposed change. Proposed changes should account for:

Additional management effort to revise the schedule and notify affected parties
The distraction of the affected parties from their primary work while they assess the impact of the proposed change
Impact on the user manual
Impact on on-line help
Impact on product specifications
Impact on product design documents
Impact on product source code
Impact on product test procedures and source code
Impact on installation program or procedures
Impact on training materials (including tutorial program, if any)
The general tendency of quality to degrade with change
The dramatically increased cost of change at later stages of the project

In the interest of efficiency, the Change Control Board may decide to queue a series of change proposals to be processed as a group. This will depend upon the frequency and importance of change proposals as determined by the board.

Approving or Rejecting Proposed Changes

Once the impact of the proposed change to each area is assessed, the Change Control Board must make a decision whether to accept or reject the proposed change. The Change Control Board may reject a proposed change out-of-hand if it determines that the cost of formally assessing the impact of the change outweighs its perceived benefit. Since defects are treated like all other change requests, the Change Control Board selects for correction only those defects which represent an acceptable benefit/risk trade-off based on the phase of the project and the distance from the next important milestone.

If accepted, the assessed impact on the development schedule must be incorporated into the existing schedule and a new schedule produced. If the Change Control Board deems it necessary, trade-offs between time, function, and manpower may be made in an attempt to mitigate the effects of change to the existing schedule. However, in no circumstances will changes be approved without sufficient consideration of their associated schedule implications.

Regardless of whether a change is approved or rejected, the following information is recorded by the defect tracking system and made available to the party submitting the change proposal (and any other interested parties that desire to monitor the progress of the work product):

The date, description, and party submitting the proposed change.
The estimated impact of the change on the development areas listed above.
The date when the change was accepted, rejected, or deferred.
If accepted, the overall impact on the project schedule (which includes the effects of any mitigating strategies and their descriptions).
If rejected, the reason for rejection.

It is suggested that those parties who have a stake in the development of the product may register their interest with the Change Control Board. The Change Control Board will then put a mechanism in place (probably by memo, e-mail, or intranet web page) to provide notification of meetings and their agenda and to disseminate the results of its actions. Interested parties may elect to attend the Change Control Board meeting in order to represent their interests.

Change Control Board

In order to manage the change control process in a fair and stable manner, a Change Control Board is established. The Change Control Board serves as the focal point for change management and retains the authority for deciding which proposed changes actually get incorporated into a work product.

For any particular project, the Change Control Board includes the following individuals:

Executive Sponsor
Customer/End-User Representative
Marketing Representative
Program Manager
Project Manager – also serves as change-board coordinator
Quality Assurance Manager
Engineering Lead
Quality Assurance Lead
Documentation Lead

It is expected that the board will meet either on a periodic basis or whenever a key change or group of changes requires consideration. The Project Manager will act as its facilitator and will serve as the focal point for collecting change requests, coordinating change board meetings, and the like.

The change control board will be considered to have a quorum if the Program Manager, Project Manager, Engineering Lead, and Quality Assurance Lead are present. These meetings may take place in person or over the telephone.

Other individuals may participate in Change Control Board actions at the discretion of the board.

Defect Tracking System

A commercial defect tracking systemwill be used to gather and manage information relating to requested modificationsof work products under formal change control. This tool will provide a central data base which contains important information as described in the preceding sections and facilitates efficient queries of the captured data in order to gain visibility over the state and number of changes to a given work product.

Approval Signatures

We, the undersigned, accept this document as a stable work product to be placed under formal change control as described by the Change Control Procedure document.

Person	Person's Signature	Date Signed
Executive Sponsor
Customer/End-User Representative
Marketing Representative
Program Manager
Project Manager
Quality Assurance Manager
Engineering Lead
Quality Assurance Lead
Documentation Lead

2006-07-24T00:54:00.000-07:00

Change Control Board (CCB)

In software development, a Change Control Board (CCB) is a committee that makes decisions regarding whether or not proposed changes to a software project should be implemented. The change control board is constituted of project stakeholders or their representatives. The authority of the change control board may vary from project to project, but decisions reached by the change control board are often accepted as final and binding.

Purpose

Describe the objectives of the CCB. It might say something like: “The Change Control Board (CCB) represents the interests of program and project management by ensuring that a structured process is used to consider proposed changes and incorporate them into a specified release of a product. The CCB shall request that impact analysis of proposed changes be performed, review change requests, make decisions, and communicate decisions made to affected groups and individuals.” Define the relationship of this CCB to any other CCBs in the organization or other decision-making bodies, such as a project steering committee.

Scope of Authority

Indicate the scope of decisions that the CCB makes. This scope could be over a specific organizational range; a project, group of projects (program), or subproject; a maximum budget or schedule impact. This scope boundary separates decisions that this CCB can make from those that it must escalate to a higher-level CCB or manager for resolution.

Membership

List the members of this CCB. The CCB typically includes representatives from program management, project management, software engineering, hardware engineering, testing, documentation, customer support, and marketing. One individual is designated as the CCB Chair. Keep the CCB as small as possible, to facilitate its ability to make rapid decisions, but make sure that the critical perspectives are represented.

Operating Procedures

State the frequency of regularly scheduled CCB meetings and the conditions that will trigger a special meeting. Describe how meetings will be conducted, the number of CCB members who constitute a quorum to make decisions at a meeting, and the roles that must be represented for the meeting to proceed. Identify whether guest participants may attend, such as the individuals who proposed the change requests being considered at a specific meeting.

Decision-Making Process

Describe how the CCB will make its decisions. Indicate whether voting, consensus, unanimity, delegation to a specific individual, or some other decision rule is used to make decisions. State whether the CCB Chair or another manager is permitted to overrule the CCB’s collective decision.

Communicating Status

Describe how each decision that the CCB makes will be communicated to the individual who requested the change, senior management, project management, affected team members who must implement the change, higher- or lower-level CCBs, and any other stakeholders. Indicate where the decisions and any supporting information, rationale, or data will be stored.

2006-07-23T00:03:00.000-07:00

Rapid Application Development (RAD)

History

Rapid Application Development was a response to non-agile processes developed in the 1970s, such as the Waterfall model. The problem with previous methodologies was that applications took so long to build that requirements had changed before the system was complete, often resulting in unusable systems. Starting with the ideas of Barry Boehm and Scott Shultz, James Martin developed the Rapid Application Development approach during the 1980s at IBM and finally formalised it by publishing a book in 1991.

Advantages and disadvantages

Rapid Application Development has two primary advantages: increased speed of development and increased quality. The speed increases are due to the use of CASE tools, the goal of which is to capture requirements and turn them into usable code as quickly as possible. Quality, as defined by RAD, is both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. RAD increases quality through the involvement of the user in the analysis and design stages.

RAD has two primary disadvantages: reduced Scalability, and reduced features. Reduced scalability occurs because a RAD developed application starts as a prototype and evolves into a finished application. Reduced features occur due to time boxing, where features are pushed to later versions in order to finish a release in a short amount of time.^{[citation needed]}

Core RAD elements

RAD has six core elements: prototyping, iterative development, time boxing, team members, management approach, and RAD tools. The first element, prototyping, is the construction of a feature-light, reduced-scalability application in a short amount of time. The objective is to create a working application to help a user flesh out requirements.

The second element, Iterative development, is the creation of increasingly feature rich versions of applications in short development cycles, where each release produces user requirements that feed the next release.

Time boxing is the third element, and supports iterative development by pushing off features to future versions in order to complete iterative cycles as quickly as possible. Time boxing is extremely important to help reduce scope creep, but it requires watchful and involved management.

The fourth RAD element, team members, specifies that teams should be small and should consist of experienced, versatile, and motivated members that are able to perform multiple roles. Ideally team members should have prior experience with the RAD methodology.

Management approach, the fifth RAD element, is an essential element specifying that management should be very involved in keeping development cycles short and enforcing deadlines. Furthermore management should help keep high team motivation, and should focus on clearing bureaucratic or political obstacles.

The sixth and last element, RAD tools, specifies that development speed is more important than cost of tools and so the latest technologies should be used to increase development speed. See the Computer-aided software engineering section for more information.

2006-07-22T23:35:00.000-07:00

Six Sigma

Six Sigma is a methodology to manage process variations that cause defects, defined as unacceptable deviation from the mean or target; and to systematically work towards managing variation to eliminate those defects^[1]. The objective of Six Sigma is to deliver high performance, reliability, and value to the end customer. It was pioneered by Bill Smith at Motorola in 1986^[2] and was originally defined^[3] as a metric for measuring defects and improving quality; and a methodology to reduce defect levels below 3.4 Defects Per (one) Million Opportunities (DPMO). Six Sigma has now grown beyond defect control.

Six Sigma is a registered service mark and trademark of Motorola, Inc^[4]. Motorola has reported over US$17 billion in savings^[5] from Six Sigma to date.

Application & Success

Starting with manufacturing, today Six Sigma is being used across a wide range of industries like banking, telecommunications, insurance, marketing, construction, healthcare^[7], and software^[8]. Some non-manufacturing examples are given below:

Healthcare

North Carolina Baptist Hospital says^[9], "The Six Sigma process improvement deployment at North Carolina Baptist Hospital is starting to show the kind of results that convert skeptics to believers." and "A Six Sigma process improvement team charged with getting heart attack patients from the Emergency Department into the cardiac catheterization lab for treatment faster slashed 41 minutes off the hospital's mean time"

Banking

Bank of America has used Six Sigma for credit risk assessment reduction, fraud prevention, and customer satisfaction improvement, etc. Bank of America's Six Sigma initiative resulted in benefits of more than US$2 billion; and increased customer satisfaction by 25%^[10].

Insurance

Insurance companies have used Six Sigma for critical tasks like premium outstanding reduction and various cycle time reductions. For example, CIGNA Dental reports pending claim volume reduction by over 50% ^[11].

Construction

In engineering and construction of the Channel Tunnel Rail Link project in the UK, the Bechtel’s project team^[12] uncovered a way to save hundreds of job hours on one of the tunneling jobs.

The Institute of Quality Assurance has interesting success stories^[13] on Wipro, Citibank, and Motorola.

Military

The United States Navy has adopted Six Sigma as part of AIRSpeed[1], an overall set of practices designed to improve efficiency in aviation maintenance. The other components of AIRSpeed are Lean and Theory of Constraints^[14].

The United States Air Force process improvement program based on Lean and Six Sigma is named Air Force Smart Operations 21 (AFSO21)^[15].

Methodology

Six Sigma has two key methodologies^[16] – DMAIC and DMADV. DMAIC is used to improve an existing business process. DMADV is used to create new product designs or process designs in such a way that it results in a more predictable, mature and defect free performance. Sometimes a DMAIC project may turn into a DFSS project because the process in question requires complete redesign to bring about the desired degree of improvement.

DMAIC

Basic methodology consists of the following five phases:

Define formally define the process improvement goals that are consistent with customer demands and enterprise strategy.
Measure to define baseline measurements on current process for future comparison. Map and measure process in question and collect required process data.
Analyze to verify relationship and causality of factors. What is the relationship? Are there other factors that have not been considered?
Improve optimize the process based upon the analysis using techniques like Design of Experiments.
Control setup pilot runs to establish process capability, transition to production and thereafter continuously measure the process and institute control mechanisms to ensure that variances are corrected before they result in defects.

DMADV

Basic methodology consists of the following five phases:

Define formally define the goals of the design activity that are consistent with customer demands and enterprise strategy.
Measure identify CTQs, product capabilities, production process capability, risk assessment, etc.
Analyze develop and design alternatives, create high-level design and evaluate design capability to select the best design.
Design develop detail design, optimize design, and plan for design verification. This phase may require simulations.
Verify design, setup pilot runs, implement production process and handover to process owners.

Also see Design for Six Sigma quality.

Some people have used DMAICR (realize). Others contend that focusing on the financial gains realized through Six Sigma is counter-productive and that said financial gains are simply byproducts of a good process improvement.

Roles Required for Implementation

Six Sigma identifies five key roles^[17] for its successful implementation.

Executive Leadership includes CEO and other key top management team members. They are responsible for setting up a vision for Six Sigma implementation. They also empower the other role holders with the freedom and resources to explore new ideas for breakthrough improvements.
Champions are responsible for the Six Sigma implementation across the organization in an integrated manner. The Executive Leadership draws them from the upper management. Champions also act as mentor to Black Belts. At GE this level of certification is now called "Quality Leader".
Master Black Belts, identified by champions, act as in-house expert coach for the organization on Six Sigma. They devote 100% of their time to Six Sigma. They assist champions and guide Black Belts and Green Belts. Apart from the usual rigor of statistics, their time is spent on ensuring integrated deployment of Six Sigma across various functions and departments.
Black Belts operate under Master Black Belts to apply Six Sigma methodology to specific projects. They devote 100% of their time to Six Sigma. They primarily focus on Six Sigma project execution, whereas Champions and Master Black Belts focus on identifying projects/functions for Six Sigma.
Green Belts are the employees who take up Six Sigma implementation along with their other job responsibilities. They operate under the guidance of Black Belts and support them in achieving the overall results.

Specific training programs are available to train people to take up these roles.

The above listed roles conform to the old Mikel Harry/Richard Schroeder model, which is far from being universally accepted. In many successful programs, both Green Belts and Black Belts lead projects, and work on problems in their existing area of responsibility.

Examples of Some Key Tools Used

Failure Modes Effects Analysis
Cost Benefit Analysis
CTQ Tree
Customer Output Process Input Supplier Maps
Customer survey
Process Maps
Run Charts
Histograms
Stratification
ANOVA Gage R&R
Cause & Effects Diagram (a.k.a. Fishbone or Ishikawa Diagram)
Homogeneity of Variance
ANOVA
Chi-Square Test of Independence and Fits
General Linear Model
Regression
Correlation
Design of Experiments
Taguchi
Control Charts
5 Whys
Axiomatic design

Criticisms of Six Sigma

Origin

Robert Galvin did not really "invent" Six Sigma in the 1980s, but would more correctly be said to have applied methodologies that had been available since the 1920s and were developed by luminaries like Shewhart, Deming, Juran, Ishikawa, Ohno, Shingo, Taguchi and Shainin. The goal of Six Sigma, then, is to use the old tools in concert, for a greater effect than a sum-of-parts approach.

The use of "Black Belts" as itinerant change agents is controversial as it has created a cottage industry of training and certification which arguably relieves management of accountability for change; pre-Six Sigma implementations, exemplified by the Toyota Production System and Japan's industrial ascension, simply used the technical talent at hand — Design, Manufacturing and Quality Engineers, Toolmakers, Maintenance and Production workers — to optimize the processes.

Meanwhile, for companies not solely devoted to manufacturing (including GE, which holds NBC Universal as a subsidiary), the spillover effects of Six Sigma have been troubling, especially as executives trained in the Six Sigma methodology for change and growth, clash with the creative minds behind less industrial business functions.

The Term Six Sigma

Sigma (the lower-case Greek letter "s") is used to represent standard deviation (a measure of variation) of a population (whereas lower-case 's', represents the estimate of the population standard deviation, based on a sample). The term "six sigma" comes from the notion that if you have six standard deviations between the mean result of a process and the nearest specification limit, you will make practically no items that exceed the specifications. This is the basis for the Process Capability Study, often used by quality professionals, and the term "Six Sigma" has its roots in this tool. Criticism of the tool itself, and the way that the term was derived from the tool, often sparks criticism of Six Sigma.

It is often said that a Six Sigma process produces 3.4 defective parts per million. A process that is normally distributed will have 3.4 parts per million beyond a point that is 4.5 standard deviations above the mean. A Capability Study on normally distributed data, mean 0, standard deviation 1, with an upper specification limit of 4.5 will confirm this. Some six sigma practitioners call this 4.5 sigma process a 6 sigma process by invoking the 1.5 sigma shift. Selection of 1.5 as the correct magnitude is completely arbitrary. And adding whatever arbitrary value is selected, rather than subtracting it, assumes that processes tend to automatically self-improve with time. The 1.5 sigma shift is a notion that has existed since before Motorola’s program, and which gets little acceptance from professional statisticians. Donald J. Wheeler, one of the most respected workers in statistics, dismisses it as "goofy".

As sample size increases, the error in the estimate of standard deviation converges much more slowly than the estimate of the mean (see confidence interval). Even with a few dozen samples, the estimate of standard deviation often drags an alarming amount of uncertainty into the Capability Study calculations. It follows that estimates of defect rates can be very greatly influenced by uncertainty in the estimate of standard deviation.

Estimates for the number of defective parts per million produced depend on knowing something about the shape of the distribution from which the samples are drawn. Unfortunately, we have no means for proving that data belong to any particular distribution. We only assume normality, based on finding no evidence to the contrary. Estimating defective parts per million down into the 100’s or 10’s of units based on such an assumption is wishful thinking, since actual defects are often deviations from normality, which have been assumed not to exist.

In summary, the term “Six Sigma” has its roots in a quality tool that can easily be misapplied by a naïve user and to the controversial 1.5 sigma shift.

Statistics and robustness

Six Sigma is controversial with the statistics profession. Some teachers of statistics are critical of the standard of statistical teaching found in Six Sigma materials. Others object to the idea that a single universal standard can be appropriate across all domains of application. They argue that quality standards should be set on a case-by-case basis using decision theory or cost-benefit analysis. Additionally, Six Sigma has been broadly criticized for clinging to the concepts of "attribute" and "variable" data, rather than the much more widely accepted "nominal", "ordinal", "interval", and "ratio" model.

The 1.5-sigma shift theory is often disputed by statisticans because the sample size is too small to make mathematically justified predictions. Also, the Six Sigma calculations might not be robust enough to handle non-normal statistics, where the measurement is not in a normal distribution (bell curve). In particular, the widely used Capability Study drags an alarmingly high level of uncertainty into its calculations, and is often assigned a greater statistical importance than it deserves.

Methods vs. Methodology

Others suggest that Six Sigma, rather than being a true methodology, is more often implemented to start an unending cycle of improvement and use of better tools on the industry day-to-day practices, rather than to use advanced statistical theories that cannot be daily applied. Six Sigma can be considered just a collection of tools and methods, rather than a methodology, itself. A full methodology, such as the Deming System (of W. Edwards Deming), would still be beneficial to address the human factors as to why some people might misrepresent measurements, including how to avoid slanted test results, how to survey customers, how to evaluate employee performance, and how to improve cooperation throughout the organization. Six Sigma has been described as a collection of superficial changes that ignore many of the major factors affecting quality and productivity.

2006-07-22T17:32:00.000-07:00

UseCases:

Click Here
PowerPoint

2006-07-22T12:13:00.000-07:00

Writing Software Requirements Specifications

Here's the scenario: You're finishing up your latest HTML Help project...no more late nights or weekends...back to a "normal" 50-hour work week. That's when the development team lead strolls into your office and says she just got your manager's okay for you to help the development team "put together the functional requirements specification template for the next major project."

"A what?" you ask with a look of semi-shock. Panic sets in. "What did I do to deserve this? I don't even know where to start! Maybe someone on the TECHWR-L list can help...."

For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional specifications or system specifications) templates or even writing SRSs, they might assume that being given the opportunity to do so is either a reward or punishment for something they did (or failed to do) on a previous project. Actually, SRSs are ideal projects for technical writers to be involved with because they lay out the foundation for the development of a new product and for the types of user documentation and media that will be required later in the project development life cycle. It also doesn't hurt that you'd be playing a visible role in contributing to the success of the project.

This article will describe what an SRS is and why it's important, discuss how and why technical writers should be involved with them, and discuss the critical elements for writing an SRS. Although this article does not attempt to address all aspects of developing SRSs, it aims to help you determine the scope for such a project, to provide some guidelines for writing SRSs, and to provide additional resources. Hopefully with this information, you'll not be asking, "Why me?" but proclaiming "Why not me?"

What is a Software Requirements Specification?

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language (versus a formal language, explained later in this article), in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.

It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed.

Why Should Technical Writers be Involved with Software Requirements Specifications?

Unfortunately, much of the time, systems architects and programmers write SRSs with little (if any) help from the technical communications organization. And when that assistance is provided, it's often limited to an edit of the final draft just prior to going out the door. Having technical writers involved throughout the entire SRS development process can offer several benefits:

Technical writers are skilled information gatherers, ideal for eliciting and articulating customer requirements. The presence of a technical writer on the requirements-gathering team helps balance the type and amount of information extracted from customers, which can help improve the SRS.

Technical writers can better assess and plan documentation projects and better meet customer document needs. Working on SRSs provides technical writers with an opportunity for learning about customer needs firsthand--early in the product development process.

Technical writers know how to determine the questions that are of concern to the user or customer regarding ease of use and usability. Technical writers can then take that knowledge and apply it not only to the specification and documentation development, but also to user interface development, to help ensure the UI (User Interface) models the customer requirements.

Technical writers, involved early and often in the process, can become an information resource throughout the process, rather than an information gatherer at the end of the process.

In short, a requirements-gathering team consisting solely of programmers, product marketers, systems analysts/architects, and a project manager runs the risk of creating a specification that may be too heavily loaded with technology-focused or marketing-focused issues. The presence of a technical writer on the team helps place at the core of the project those user or customer requirements that provide more of an overall balance to the design of the SRS, product, and documentation.

What Kind of Information Should an SRS Include?

You probably will be a member of the SRS team (if not, ask to be), which means SRS development will be a collaborative effort for a particular project. In these cases, your company will have developed SRSs before, so you should have examples (and, likely, the company's SRS template) to use. But, let's assume you'll be starting from scratch. Several standards organizations (including the IEEE) have identified nine topics that must be addressed when designing and writing an SRS:

Interfaces

Functional Capabilities

Performance Levels

Data Structures/Elements

Safety

Reliability

Security/Privacy

Quality

Constraints and Limitations

But, how do these general topics translate into an SRS document? What, specifically, does an SRS document include? How is it structured? And how do you get started? An SRS document typically includes four ingredients, as discussed in the following sections:

A template

A method for identifying requirements and linking sources

Business operation rules

A traceability matrix

Begin with an SRS Template

The first and biggest step to writing an SRS is to select an existing template that you can fine tune for your organizational needs (if you don't have one already). There's not a "standard specification template" for all projects in all industries because the individual requirements that populate an SRS are unique not only from company to company, but also from project to project within any one company. The key is to select an existing template or specification to begin with, and then adapt it to meet your needs.

In recommending using existing templates, I'm not advocating simply copying a template from available resources and using them as your own; instead, I'm suggesting that you use available templates as guides for developing your own. It would be almost impossible to find a specification or specification template that meets your particular project requirements exactly. But using other templates as guides is how it's recommended in the literature on specification development. Look at what someone else has done, and modify it to fit your project requirements. (See the sidebar called "Resources for Model Templates" at the end of this article for resources that provide sample templates and related information.)

Table 1 shows what a basic SRS outline might look like. This example is an adaptation and extension of the IEEE Standard 830-1998:

Table 1 A sample of a basic SRS outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

Table 2 shows a more detailed SRS outline, showing the structure of an SRS template as found on Ken Rigby's informative Web site at http://neon.airtime.co.uk/users/wysywig/srs_mt.htm. Reprinted with permission.

Table 2 A sample of a more detailed SRS outline

1. Scope	1.1 Identification. Identify the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s). 1.2 System overview. State the purpose of the system or subsystem to which this document applies. 1.3 Document overview. Summarize the purpose and contents of this document. This document comprises six sections: Scope Referenced documents Requirements Qualification provisions Requirements traceability Notes Describe any security or privacy considerations associated with its use.
2. Referenced Documents	2.1 Project documents. Identify the project management system documents here. 2.2 Other documents. 2.3 Precedence. 2.4 Source of documents.
3. Requirements	This section shall be divided into paragraphs to specify the Computer Software Configuration Item (CSCI) requirements, that is, those characteristics of the CSCI that are conditions for its acceptance. CSCI requirements are software requirements generated to satisfy the system requirements allocated to this CSCI. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. 3.1 Required states and modes. 3.2 CSCI capability requirements. 3.3 CSCI external interface requirements. 3.4 CSCI internal interface requirements. 3.5 CSCI internal data requirements. 3.6 Adaptation requirements. 3.7 Safety requirements. 3.8 Security and privacy requirements. 3.9 CSCI environment requirements. 3.10 Computer resource requirements. 3.11 Software quality factors. 3.12 Design and implementation constraints. 3.13 Personnel requirements. 3.14 Training-related requirements. 3.15 Logistics-related requirements. 3.16 Other requirements. 3.17 Packaging requirements. 3.18 Precedence and criticality requirements.
4. Qualification Provisions	To be determined.
5. Requirements Traceability	To be determined.
6. Notes	This section contains information of a general or explanatory nature that may be helpful, but is not mandatory. 6.1 Intended use. This Software Requirements specification shall ... 6.2 Definitions used in this document. Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the "Documentation standard." 6.3 Abbreviations used in this document. Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the "Documentation Standard." 6.4 Changes from previous issue. Will be "not applicable" for the initial issue. Revisions shall identify the method used to identify changes from the previous issue.

Identify and Link Requirements with Sources

As noted earlier, the SRS serves to define the functional and nonfunctional requirements of the product. Functional requirements each have an origin from which they came, be it a use case (which is used in system analysis to identify, clarify, and organize system requirements, and consists of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal), government regulation, industry standard, or a business requirement. In developing an SRS, you need to identify these origins and link them to their corresponding requirements. Such a practice not only justifies the requirement, but it also helps assure project stakeholders that frivolous or spurious requirements are kept out of the specification.

To link requirements with their sources, each requirement included in the SRS should be labeled with a unique identifier that can remain valid over time as requirements are added, deleted, or changed. Such a labeling system helps maintain change-record integrity while also serving as an identification system for gathering metrics. You can begin a separate requirements identification list that ties a requirement identification (ID) number with a description of the requirement. Eventually, that requirement ID and description become part of the SRS itself and then part of the Requirements Traceability Matrix, discussed in subsequent paragraphs. Table 3 illustrates how these SRS ingredients work together.

Table 3 This sample table identifies requirements and links them to their sources

ID No.	Paragraph No.	Requirement	Business Rule Source
17	5.1.4.1	Understand/communicate using SMTP protocol	IEEE STD xx-xxxx
18	5.1.4.1	Understand/communicate using POP protocol	IEEE STD xx-xxxx
19	5.1.4.1	Understand/communicate using IMAP protocol	IEEE STD xx-xxxx
20	5.1.4.2	Open at same rate as OE	Use Case Doc 4.5.4

Establish Business Rules for Contingencies and Responsibilities

"The best-laid plans of mice and men..." begins the famous saying. It has direct application to writing SRSs because even the most thought-out requirements are not immune to changes in industry, market, or government regulations. A top-quality SRS should include plans for planned and unplanned contingencies, as well as an explicit definition of the responsibilities of each party, should a contingency be implemented. Some business rules are easier to work around than others, when Plan B has to be invoked. For example, if a customer wants to change a requirement that is tied to a government regulation, it may not be ethical and/or legal to be following "the spirit of the law." Many government regulations, as business rules, simply don't allow any compromise or "wiggle room." A project manager may be responsible for ensuring that a government regulation is followed as it relates to a project requirement; however, if a contingency is required, then the responsibility for that requirement may shift from the project manager to a regulatory attorney. The SRS should anticipate such actions to the furthest extent possible.

Establish a Requirements Traceability Matrix

The business rules for contingencies and responsibilities can be defined explicitly within a Requirements Traceability Matrix (RTM), or contained in a separate document and referenced in the matrix, as the example in Table 3 illustrates. Such a practice leaves no doubt as to responsibilities and actions under certain conditions as they occur during the product-development phase.

The RTM functions as a sort of "chain of custody" document for requirements and can include pointers to links from requirements to sources, as well as pointers to business rules. For example, any given requirement must be traced back to a specified need, be it a use case, business essential, industry-recognized standard, or government regulation. As mentioned previously, linking requirements with sources minimizes or even eliminates the presence of spurious or frivolous requirements that lack any justification. The RTM is another record of mutual understanding, but also helps during the development phase.

As software design and development proceed, the design elements and the actual code must be tied back to the requirement(s) that define them. The RTM is completed as development progresses; it can't be completed beforehand (see Table 3).

What Should I Know about Writing an SRS?

Unlike formal language that allows developers and designers some latitude, the natural language of SRSs must be exact, without ambiguity, and precise because the design specification, statement of work, and other project documents are what drive the development of the final product. That final product must be tested and validated against the design and original requirements. Specification language that allows for interpretation of key requirements will not yield a satisfactory final product and will likely lead to cost overruns, extended schedules, and missed deliverable deadlines.

Table 4 shows the fundamental characteristics of a quality SRS, which were originally presented at the April 1998 Software Technology Conference presentation "Doing Requirements Right the First Time." Reprinted with permission from the Software Assurance Technology Center at NASA (http://www.gsfc.nasa.gov/). These quality characteristics are closely tied to what are referred to as "indicators of strength and weakness," which will be defined next.

Table 4 The 10 language quality characteristics of an SRS

SRS Quality Characteristic	What It Means
Complete	SRS defines precisely all the go-live situations that will be encountered and the system's capability to successfully address them.
Consistent	SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets.
Accurate	SRS precisely defines the system's capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs.
Modifiable	The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify).
Ranked	Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents.
Testable	An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself.
Traceable	Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.)
Unambiguous	SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language.
Valid	A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language.
Verifiable	A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present.

What makes an SRS "good?" How do we know when we've written a "quality" specification? The most obvious answer is that a quality specification is one that fully addresses all the customer requirements for a particular product or system. That's part of the answer. While many quality attributes of an SRS are subjective, we do need indicators or measures that provide a sense of how strong or weak the language is in an SRS. A "strong" SRS is one in which the requirements are tightly, unambiguously, and precisely defined in such a way that leaves no other interpretation or meaning to any individual requirement.

The Goddard Space Flight Center (GSFC) studied dozens of NASA requirements specifications that revealed nine categories of SRS quality indicators. The individual components in each category are words, phrases, and sentence structures that are related to quality attributes. The nine categories fall into two classes: those related to individual specification statements, and those related to the total SRS document. Table 5 summarizes the classes, categories, and components of these quality indicators. This table was also originally presented at the April 1998 Software Technology Conference presentation "Doing Requirements Right the First Time." Reprinted with permission from the Software Assurance Technology Center at NASA (http://www.gsfc.nasa.gov/).

Table 5 Quality measures related to individual SRS statements

Imperatives: Words and phrases that command the presence of some feature, function, or deliverable. They are listed below in decreasing order of strength.
Shall	Used to dictate the provision of a functional capability.
Must or must not	Most often used to establish performance requirement or constraints.
Is required to	Used as an imperative in SRS statements when written in passive voice.
Are applicable	Used to include, by reference, standards, or other documentation as an addition to the requirement being specified.
Responsible for	Used as an imperative in SRSs that are written for systems with pre-defined architectures.
Will	Used to cite things that the operational or development environment is to provide to the capability being specified. For example, The vehicle's exhaust system will power the ABC widget.
Should	Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs.
Continuances: Phrases that follow an imperative and introduce the specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point. Excessive use of continuances often indicates a very complex, detailed SRS. The continuances below are listed in decreasing order of use within NASA SRSs. Use continuances in your SRSs, but balance the frequency with the appropriate level of detail called for in the SRS. 1. Below: 2. As follows: 3. Following: 4. Listed: 5. In particular: 6. Support:
Directives: Categories of words and phrases that indicate illustrative information within the SRS. A high ratio of total number of directives to total text line count appears to correlate with how precisely requirements are specified within the SRS. The directives below are listed in decreasing order of occurrence within NASA SRSs. Incorporate the use of directives in your SRSs. 1. Figure 2. Table 3. For example 4. Note
Options: A category of words that provide latitude in satisfying the SRS statements that contain them. This category of words loosens the SRS, reduces the client's control over the final product, and allows for possible cost and schedule risks. You should avoid using them in your SRS. The options below are listed in the order they are found most often in NASA SRSs. 1. Can 2. May 3. Optionally
Weak phrases: A category of clauses that can create uncertainty and multiple/subjective interpretation. The total number of weak phrases found in an SRS indicates the relative ambiguity and incompleteness of an SRS. The weak phrases below are listed alphabetically.
adequate	be able to	easy	provide for
as a minimum	be capable of	effective	timely
as applicable	but not limited to	if possible	tbd
as appropriate	capability of	if practical
at a minimum	capability to	normal
Size: Used to indicate the size of the SRS document, and is the total number of the following: 1. Lines of text 2. Number of imperatives 3. Subjects of SRS statements 4. Paragraphs
Text Structure: Related to the number of statement identifiers found at each hierarchical level of the SRS and indicate the document's organization, consistency, and level of detail. The most detailed NASA SRSs were nine levels deep. High-level SRSs were rarely more than four levels deep. SRSs deemed well organized and a consistent level of detail had text structures resembling pyramids (few level 1 headings but each lower level having more numbered statements than the level above it). Hour-glass-shaped text structures (many level 1 headings, few a mid-levels, and many at lower levels) usually contain a greater amount of introductory and administrative information. Diamond-shaped text structures (pyramid shape followed by decreasing statement counts at levels below the pyramid) indicated that subjects introduced at higher levels were addressed at various levels of detail.
Specification Depth: The number of imperatives found at each of the SRS levels of text structure. These numbers include the count of lower level list items that are introduced at a higher level by an imperative and followed by a continuance. The numbers provide some insight into how much of the Requirements document was included in the SRS, and can indicate how concise the SRS is in specifying the requirements.
Readability Statistics: Measurements of how easily an adult can read and understand the requirements document. Four readability statistics are used (calculated by Microsoft Word). While readability statistics provide a relative quantitative measure, don't sacrifice sufficient technical depth in your SRS for a number. 1. Flesch Reading Ease index 2. Flesch-Kincaid Grade Level index 3. Coleman-Liau Grade Level index 4. Bormuth Grade Level index

Conclusion

There's so much more we could say about requirements and specifications. Hopefully, this information will help you get started when you are called upon--or step up--to help the development team. Writing top-quality requirements specifications begins with a complete definition of customer requirements. Coupled with a natural language that incorporates strength and weakness quality indicators--not to mention the adoption of a good SRS template--technical communications professionals well-trained in requirements gathering, template design, and natural language use are in the best position to create and add value to such critical project documentation.

Additional Resources

Brooks, Frederick P. Jr., No Silver Bullet: Essence and accidents of software engineering, IEEE Computer, vol. 15, no. 1, April 1987, pp. 10-18.

Gause, Donald C., and Weinberg, Gerald M., Exploring Requirements Quality Before Design, Dorset House Publishing, NY, NY, 1989.

IEEE Std 830-1993, Recommended Practice for Software Requirements Specifications, December 2, 1993.

Wiegers, Karl E. Software Requirements, Microsoft Press, Redmond, WA, 1999.

Resources for Model Templates

As previously noted, you should first look for SRS documents developed by your company. Not only are these documents readily available to you, but also they're likely for products that are similar to the product you're developing an SRS for. Additional resources include:

IEEE Standard 830-1998 describes an SRS template (Table 1 is an adaptation and extension of this template).

Ken Rigby's informative Web site at http://neon.airtime.co.uk/users/wysywig/srs_mt.htm includes sample specification templates and articles about writing various types of specifications.

STC's Management Special Interest Group (SIG) offers a Reference Documents Page at http://www.stcsig.org/mgt/reference.htm that includes a sample template and other related resources.

Other sites are also available on the Web that offer examples of actual SRSs and templates. A quick search for "software requirements specifications" at your favorite search engine should yield some useful results.

2006-07-22T02:45:00.000-07:00

A giude to Business Analysis: Body of knowledge

The business analysis (BA) body of knowledge (bok) is a massive 329 page pdf ebook that strives to include “everything” needed for the very broad role of business analysts.

Click on the link above to download.

2006-07-22T02:17:00.000-07:00

Requirements Gathering - Interviewing the Right People

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

It isn’t much different for most software users. Users don’t typically know what software can do, or don’t have the skills to synthesize software based solutions to their real problems. Users are rarely the source of innovative solutions. So how do we gather the real requirements?

We can make our user interviews much more valuable by talking to different users. We can use Geoffrey Moore’s Crossing the Chasm description of technology adoption as a basis for segmenting our users. Ken Norton proposes that we do exactly this, and combine the different perspectives to reach our conclusions.

Classifying Users

We use personas to identify different classes of users in a software system. We use those personas to drive feature prioitization and design decisions. When making design decisions, we focus on the level of competence of the users to prioritize features. When we are eliciting requirements, it is before we get to the prioritization stage, and we are still defining what the features might be.

We can use the same techniques to increase the value of our requirements elicitation efforts.

For any given role that we identify as a user of our software, we can use Geoffrey Moore’s classification to identify four distinct user archetypes (personas).

Innovators (Influencers) - people on the bleeding edge of the technology curve.
Early Adopters - our first customers.
Majority - most users of our software.
Late Adopters - people who follow the crowd.

There are pros and cons to interviewing representatives from each group. With Ken’s guidance, we can separate the wheat from the chaff and combine their inputs to drive innovative and valuable solutions. Our goal in these interviews is to understand the pain-points and market opportunities.

Innovators

pro - Innovators can prevent tragically bad mistakes. They can also help us to identify opportunities to solve problems most people don’t realize are problems.
con - Innovators struggle to distinguish cool from valuable. There is also a risk that they can fixate on something that is irrelevant.

Early Adopters

pro - Early Adopters easily develop a deep understanding of our products and goals. They can tell us in advance what problems majority users will face, and provide a bit of a sanity check on the ‘problems’ that innovators suggest
con - Early Adopters tend to be power users, and are genuinely enthused about our product ideas. They tend to gloss over the negatives and focus on the positives. They also tend to communicate in terms of features, not capabilities.

Majority

pro - Majority users can give us the best insight into what is painful. We can use this insight to drive market requirements and solution ideas.
con - Majority users don’t think about software, they think about how software affects them. We have to keep a focus on the problem not the solution when gathering requirements. We also have to dig deeper with why questions to understand the underlying cause of a particular problem.

Late Adopters

pro - Late Adopters avoid change. Use them to help us identify where we need better interaction design and more documentation.
con - Late Adopters will drive us towards “… just like product X” solutions. They will be disinterested in novel solutions until they are mainstream.

Triangulation

Ideas that survive the innovator-filter, make sense to early adopters, and solve a painful problem for the majority are the ones that we want. The late adopters won’t be using early versions of our software, so we can focus our attention on the other groups until we become the dominant solution. Then we can look to the late adopters to help us manage incremental improvements.

Thanks Ken for suggesting that we triangulate these perspectives into great ideas!

Conclusion

Even if we don’t go out in search of these archetypes, we should try and understand the people we do talk to, and put their inputs into the proper perspective.

2006-07-22T02:06:00.000-07:00

Tips and techniques to improve the quality of system use-case models

Write from the point of view of the actor and in the active voice

Use cases should be written in the active voice: "The student indicates the seminar," instead of in the passive voice, "The seminar is indicated by the student." Furthermore, use cases should be written from the point of view of the actor. After all, the purpose of use cases is to understand how your users will work with your system.

Write scenario text, not functional requirements

A use case describes a series of actions that provide value to an actor; it doesn't describe a collection of features. For example, the "Enroll Student in Seminar" use case describes how a student interacts with the system to sign up for a seminar. It doesn't describe what the user interface looks like or how it works. You have other models to describe this important information, such as your user interface model and your supplementary specifications. Object-oriented analysis is complex, which is why you have several models to work with, and you should apply each model appropriately.

Use cases only document behavioral requirements

A use case is neither a class specification nor a data specification. This is the sort of information that should be captured by your conceptual model, which in the object world is modeled via a UML class model. You are likely to refer to classes described in your conceptual model, for example, the "Enroll in Seminar" use case includes concepts, such as seminars and students, both of which would be described by your conceptual model.

Don't forget the user interface

System use cases often refer to major user interface (UI) elements, often called boundary or user interface items, such as HTML pages and reports. Use cases will sometimes refer to minor UI elements, such as buttons or data entry fields, although this level of detail is not as common.

Create a use case template

Use cases include a fair amount of information, information that can easily be documented in a common format. You should consider developing your own template (see the tip "Documenting a Use Case)."

Organize your use-case diagrams consistently

Common practice is to draw inheritance and extend associations vertically, with the inheriting/extending use case drawn below the parent/base use case. Similarly, include associations are typically drawn horizontally. Note that these are simple rules of thumb -- rules that, when followed consistently, result in diagrams that are easier to read.

Don't forget the system responses to the actions of actors

Your use cases should describe both how your actors interact with your system and how your system responds to those interactions. For example, with the "Enroll in Seminar" use case, if the system does not respond when the student indicates they want to enroll in a seminar, the student would soon become discouraged and walk away.

Alternate courses of action are important

Start with the happy path, the basic course of action -- but don't forget the alternate courses as well. Alternate courses will be introduced to describe potential usage errors, as well as business logic errors and exceptions. This important information is needed to drive the design of your system, so don't forget to model it in your use cases.

Don't get hung up on <> and <> associations.

I'm not quite sure what happened, but I've always thought the proper use of include and extend associations, as well as uses and extends associations in older versions of the UML, were never described well. As a result, use-case modeling teams had a tendency to argue about the proper application of these associations, wasting an incredible amount of time on an interesting, but minor, portion of the overall modeling technique. I even worked at one organization that went so far as to outlaw the use of the <> and <> stereotypes, an extreme solution that had to be reversed after a few weeks when it was realized that the company still needed these concepts, even though the organization hadn't come to a full agreement as to their proper use.

Let use cases drive user documentation

The purpose of user documentation is to describe how to work with your system. Each use case describes a series of actions taken by actors using your system. In short, use cases contain the information from which you can start writing your user documentation. For example, the "how to enroll in a seminar" section of your system's user documentation could be written using the "Enroll in Seminar" use case as its base.

Let use cases drive presentations

Part of software development is communicating your work efforts with project stakeholders, resulting in the occasional need to give presentations. Because use cases are written from the point of view of your users, they contain valuable insight into the type of things your stakeholders are likely to want to hear about in your presentations. In other words, use cases often contain the logic from which to develop presentation scripts.

2006-07-22T02:03:00.000-07:00

Writing Good Requirements - The Big Ten Rules

Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.

Pragmatic’s List (1-8) + Two More

~~Necessary~~ Valuable
Concise
Design Free
Attainable
Complete
Consistent
Unambiguous
Verifiable
Atomic
Passionate

Looking at each rule of writing good requirements…

1. Valuable

Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important - even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.

Requirements that can differentiate our product from the competition are by definition not necessary - or the competition would have done it already.

[Update: Our detailed article on Writing Valuable Requirements ]

2. Concise

Easy to read and understand. If only it were that easy. For whom is it easy to read? A market requirements document (MRD) is written for several different people on the team. It provides a vision of what problems our product solves. It provides clarification to the implementation team. It also sets expectations with stakeholders. Different people on the team have different domains of expertise - we have to write requirements that are easily understood by all of them.

[Update: Our detailed article on Writing Concise Requirements]

3. Design Free

Generally, a requirement should not specifiy any of the implementation choices. From a product manager’s perspective the requirement is the ‘what’ and the spec is the ‘how’. To a system designer or architect or lead developer, the requirement serves as a ‘why’.

[Update: Our detailed article on Writing Design-Free Requirements]

4. Attainable

The requirement must be realistically achievable. Barbara and Steve make great points about understanding the cost of implementing something as expressed in the requirements. As we pointed out in our thoughts about good requirements management, there is an optimal tradeoff between costs and benefits for any given company or project. We can formally approach this using the techniques identified for more is better requirements using a Kano framework. In short, the investment must have an ROI that exceeds the opportunity costs by the hurdle rate.

Looking at cost-benefit tradeoffs also supports the argument that valuable should replace necessary.

[Update: Our detailed article on Writing Attainable Requirements]

5. Complete

Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.

[Update: Our detailed article on Writing Complete Requirements]

6. Consistent

Pragmatic highlights that the requirement must be logically consistent with the other requirements in the document - no overlaps, no contradictions, no duplications. This is certainly the most important point of consistency.

There is also benefit to consistent writing in an MRD. We can use templates to provide a consistent framework, but more importantly the prose needs to be consistent. This consistency makes it easier on the readers.

[Update: Our detailed aricle on Writing Consistent Requirements]

7. Unambiguous

A great requirement has a single interpretation. A good requirement has a single reasonable interpretation. As part of our development process, we will use listening skills like active listening to make sure that our engineering team understands the requirement we intended to write. The better the requirements, the less expensive and risky this communication process will be. Writing unambiguously is critically important when using outsourcing models that limit our interactions with other team members.

[Update: Our detailed article on Writing Unambiguous Requirements]

8. Verifiable

We use a process that starts with market requirements, and then decomposes them into software requirement specifications. the market requirements must be written in a way that we can verify that the associated requirements specification will meet the market need.

[Update: Our detailed article on Writing Verifiable Requirements]

9. Atomic

Every requirement should be a single requirement. If we can say “Half of this requirement is implemented” then this needs to be two or more requirements. If a requirement read “Sales reps can manage their client list and generate custom reports” it expresses two atomic ideas (list management and report generation). Those ideas need to be separated

[Update: Our detailed article on Writing Atomic Requirements]

10. Passionate

Nothing great has been born from complacency, lethargy or mediocrity. When we are defining requirements, we must be passionate about what we’re doing. If we’re just going through the motions, it shows up in the writing. If we aren’t excited about a requirement, the problem is either with us or with the requirement. Either way, it won’t inspire the rest of the team to do something great.

[Update: Our detailed article on Writing Passionate Requirements]

2006-07-22T02:01:00.000-07:00

The 8 Goals of Use Cases

Why do we write use cases?

We write use cases for the same reasons that people use our software - to achieve goals. In our case, we want to assure that we are creating the right software. By looking at this high level goal in more detail, we can make decisions that drive the best possible use case creation. Let’s apply our product management skills to writing better use cases by writing an MRD for use cases.

This article can be used as a guide to develop a process for defining, documenting and gathering use cases. It can be used to define a template for use cases, and it can be used to define specifications for a use case management system. We will start with a market analysis and a vision statement, and then create our market requirements.

Market Analysis

69% of software projects failed or were delayed in 2003 according to the Standish Group’s latest study.(1994 study, 2001 study)
40% to 60% of problems were attributed to bad requirements.
Current investments are focused on coding efficiency not requirement quality.
Incremental delivery is becoming more common as teams adopt different forms of agile processes. This increases the frequency of requirements changes during projects.

Bad requirements are further detailed as the following:

Requirements that are overlooked cause us to fail to meet expectations and fail to deliver value.
Requirements that are incorrect cause us to incorrectly address problems and fail to deliver value.
Requirements that are poorly communicated cause us to implement incorrectly, failing to address problems and deliver value.
Requirements that are low-value cause us to spend time and money on problems that don’t maximize value.

Through the course of any long term project, requirements will change. This happens more when we use iteration and prototyping to accelerate stakeholder feedback cycles. But that’s a good thing, because the changes result in better requirements. Agile development methodologies like feature driven development supercharge this phenomenon.

Vision Statement

We will improve our ability to write and manage use cases so that we may maximize their impact on

Writing and maintaining great requirements
to improve our ability to deliver the right functionality
and ultimately achieve software product success

Market Requirements

With an understanding of the market problems and a guiding vision, we will document the market requirements for writing better use cases. The market requirements have an explicit scope - they specify which and how much of the market problems we intend to address.

When we use the phrase ‘our use cases‘, we are really saying ‘our use cases and our approach to managing the use cases.’ We’re using shorthand to improve the readability.

Prioritization of the requirements is denoted with (H) (M) or (L) prepending the requirement, representing high, medium and low priority requirements, respectively.

Requirements that are overlooked

1. (M) Our use cases must support validation of requirement completeness. [Update: Detailed article on this goal.]

Requirements that are incorrect

2. (L) Our use cases must support validation of requirement correctness. [Update: Detailed article on this goal.]

Requirements that are poorly communicated

3. (H) Our use cases must improve communication with stakeholders about the intended content of the system. [Update: Detailed article on this goal.]
4. (H) Our use cases must improve communication with the implementation team (dev + test) about the intended content of the system. [Update: Detailed article on this goal.]
5. (M) Our use cases must improve communication about the release-planning (delivery schedule) for the system to both stakeholders and implementers. [Update: Detailed article on this goal.]
6. (H) Our use cases must improve communication of the scope of proposed requirements changes to developers.
7. (L) Our use cases must improve communication of the impact of requirements change proposals to stakeholders.

Requirements that are low-value

8. (L) Our use cases must support prioritization of requirements across releases.

Conclusion

These goals define why we write use cases as part of software development. We do it to improve our ability to write the right software to solve our customer’s problems. We also write use cases to help us manage requirements changes and set delivery expectations with our stakeholders.

2006-07-22T01:56:00.000-07:00

Business Process Modeling

Business Process Modeling

Business Process Modeling (BPM) allows us to increase our understanding of business processes and improve communication with stakeholders and implementation teams. Business analysts will create diagrams that represent business processes. These diagrams can be used to elicit requirements, define scope, and improve communication within the team.

We use diagrams because they are intuitive. Diagrams can provide us with an easy to remember and understand visualization of a business process. These diagrams are a type of object oriented analysis (OOA) diagram. A BPM describes a business process, where an entity-relationship (ER) diagram describes business objects. The example in the previous link is an ER diagram.

A Simple Process Model

The easiest way to get a high level understanding of a business process model is to review the diagram for a simple process.
The following diagram represents a customer withdrawing money from their bank account. The customer convinces the bank that she is allowed to withdraw money, then requests the money, which the bank provides (after confirming that it is available). The customer then terminates the transaction.

The diagram does not show exceptions to the process, like having the wrong password, or not having enough funds in their account. Business process models can absolutely demonstrate these situations, and many others. We’ve kept this process simple, as it is an introduction to the concept.

The BPM Example Diagram

Swim Lanes and Pools

The first thing you will notice about the diagram is that all the activities happen in one of two areas, labeled customer and bank. These two areas are called pools. While that seems like a silly name, there is a reason for it. There is a type of diagram called swim lanes, designed to show how different people or entities interact. Each person gets a swim lane in which all of her actions happen. In BPM, all of the swim lanes for a single company are grouped together in a pool. In our example, each pool has a single lane.

In our diagram, there are two pools - one for the customer, and one for the bank.

Flow Objects

Our diagram includes examples of three flow objects: events, activities, and gateways. Events are represented as circles. We have starting events (triggers) at the top of the diagram and ending events at the bottom. Activities are drawn as rounded rectangles. An activity can be a single task (like “confirm logout”), or they can represent an entire sub-process. Our simple example shows only tasks.

Gateways represent points in the process where the flow can separate or combine. The diamond is the symbol used to represent a gateway - and it is common to see it in a flow chart, showing how a decision can cause a process to go in one of two directions. The two examples in our diagram show flows combining, with a “+” symbol inside the diamond. This implies that both inputs are required for the process to continue. For example, the steps “Deliver Cash” and “Update Account Balance” must both be completed before the sytem can “Receive [the] Logout Command”.

Sequence Flow

The solid arrows that connect all of the items within each pool are called sequence flows. They represent the flow of the process from one flow object to the next. Notice that there are no sequence flows from one pool to another. These solid arrows can cross swim-lane boundaries within a single pool, but never across pool boundaries. Since our example has a single swim lane in each pool, we don’t see this.

Message Flow

The dashed arrows that cross the pool boundaries are called message flows. A message flow represents communication between two entities. In our example, the customer sends a message to the bank asking for $100. The bank sends a message to the customer in the form of $100.

A Lot More

There are a lot more details to BPM. We’ve left them out to keep the introduction simple (and “brief”).

BPMN Standard

There is a standard notation to use in business process modeling, called BPMN. Business Process Modeling Notation is the industry standard for drawing diagrams. By using the same notation, every diagram becomes easier to read. All of the official documents can be found at www.bpmn.org.

2006-07-22T01:50:00.000-07:00

JAD Session

JAD stands for Joint Application Development. It's one of those software engineering techniques that some folks with lots of time on their hands sat around and dreamed up. All the design methodologies like this are complicated replacements for a huge dollop of common sense. Sit down with the client and design a paper UI that they can see what the application will look like and behave like. Give the user a chance to work through common scenarios and see if the application will work for them. Keep refining until the user feels the application is doing what they want it to do. As you get functionality implemented, bring the user in and have them work through those scenarios and see if it still works.

On a more serious note, According to Wiki "JAD is a popular Fact-finding technique that brings users into the development process as active participants"

A Typical JAD session agenda:

Project leader: 1) Introduce all JAD team members 2) Discuss ground rules, goals, and objectives for the JAD sessions 3) Explain methods of documentation and use of CASE tools, if any

Top management : Explain the reason for the project and express top management authorization and support.

Project Leader: 1) Provide overview of the current system and proposed project scope and constraints 2) Present outline of specific topics and issues to be investigated.

Open discussion session, moderated by project leader: 1) Review the main business processes, tasks, user roles, input, and output 2) Identify specific areas of agreement or disagreement 3) Break team into smaller groups to study specific issues and assign group leaders.

JAD team members working in smaller group sessions, supported by IT staff: 1) Discuss and document all system requirements 2) Develop models and prototypes.

Group leaders: 1) Report on results and assigned tasks and topics 2) Present issues that should be addressed by the overall JAD team

Open discussion session, moderated project leader: 1) Review reports from small group sessions 2) Reach consensus on main issues 3) Document all topics

Project leader: 1) Present overall recap of JAD session 2) Prepare report that will be sent to JAD team members

Typical JAD's :

Business Process Modeling JAD
Business Rules Definition JAD
Business Data Modeling JAD
Requirements Gathering JAD
Quick Fix Design JAD
Test Planning JAD

To sum it up :

Joint Application Development (JAD) enables a group of people to grasp complex issues quickly and make informed decisions.

The core component of JAD is a structured, facilitated workshop that focuses on creating specified deliverables based on the group's input.

It is an effective tool for planning a project, designing a solution, defining requirements, or any other process that requires consensus-based decision making across functional areas.

2006-07-22T01:48:00.000-07:00

Role of BA in the system development life cycle

The BA plays a central role in the system development life cycle (SDLC). In general terms, the SDLC contains well-defined phases which are executed by the project team:

A business idea or request,
Feasibility (business case)
Planning (business requirements, functional requirements)
Delivery (Coding, execution of activities)
Testing (test cases, unit testing, integration testing, user acceptance testing)
Implementation (roll out of the idea or request)
Close out (documentation, post implementation review)

This is also known as project methodology. A version of the SDLC is part of many different Project Methodologies such as RAD, SDM, Rational Unified Process.

The BA will provide different services during the SDLC:

Assisting with the Business case
High level feasibility
Gathering of the requirements
Designing and/or reviewing test cases
Processing change requests
Tracing the requirements during implementation (traceability matrix).
Manage scope
Acceptance, Installation, deployment

2006-07-22T01:44:00.000-07:00

Top five ways to be a better listener

Great listening skills yield great requirements

The better you are at listening, the more people will want to tell you.

If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is listening. A marriage counselor will tell you that step one in solving your problems is to listen. Consulting 101 will reiterate the importance of listening. Presentation trainers stress listening. Dale Carnegie - listening yet again. Sonar technician. There’s a pattern.

Listening is not enough, however - just being a good listener is important, but not sufficient to assure success. Listening is critical to interaction, compromise, partnership, discovery, and almost every significant component of working with others. And requirements management depends upon having the skills to work with other people.

Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating.

With good listening skills, you not only hear better - people say more!

Top five ways to be a better listener

Use active listening. This is my desert-island* listening skill. When we confirm actively that what we just heard is what the other person just said, we avoid a lot of mistakes - and it encourages that person to tell us more. It also tells our speaker that we are “getting it” and she isn’t wasting her time.
Have attentive body language. Smile. Make eye contact (not creepy stalker eye contact). Square your body so that you’re facing whoever your talking with. Don’t fidget or look impatient. Don’t check your watch (if you have an important meeting - tell the person before you start talking that you need to check the time - or that you’ve set an alarm on your phone for five minutes before you have to leave). And whatever you do - don’t answer the phone if someone calls. Nothing sends a stronger “what you are saying is important to me” message than sending your phone to voicemail without checking who the caller is.
Ask questions. Get clarifications to statements. Ask the person why. There are several questioning techniques we’ve talked about before, and they help us with eliciting requirements. They also give feedback to the speaker that we are interested in what they are saying. Anyone who’s lectured or presented to a room of dead fish knows how tough it can be to not get any questions.
100% focus. Don’t multi-task when you’re listening to someone. No instant-messaging or answering emails. Don’t get distracted by the urgent matter that just came up. We can reschedule the meeting for when we aren’t overwhelmed, or we can take a couple minutes to compose ourselves, focus on the meeting/interview, and relax. We can review our notes about what we want to talk about before we go in - and get our head in the game. If we’re going to talk to Tony for an hour - it’s Tony’s hour.
Use non-verbal attends. Nod your head, validate what you hear with a quick glance to the expert in the room, clap your hands, grab a pen and scrawl down some notes. Any reaction to a particular point made by the person speaking is a non-verbal attend. If you give the person this positive, genuine feedback, they will open up, become more comfortable, and talk more. And therefore tell you more.

2006-07-22T01:41:00.000-07:00

How To Interview When Gathering Requirements

The importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.

Understanding why is still our goal - but we have to be smart about our interviews to get this information. In our previous post, we identify interviewing as a key technique for eliciting requirements. Interviewing is the cornerstone of our elicitation techniques - even if we gather the bulk of our information in group meetings, we have to follow-up, clarify and validate with individuals. There’s truth behind the old saw that nothing good is designed by committee.

Before the interview
Failing to plan is planning to fail. OK, stop groaning, I know it’s a cliche. Regardless, the first thing we do when interviewing is identify who we need to speak to, and what we need to speak about. If we’re going to talk to a sales manager, about our sales-support software, we will likely talk about user adoption, business processes, and the organization of the sales team. If we are talking to a sales person (a representative user), we will talk about how they do their job today, and how it could be different with the new software. In both cases, we plan our conversation before we have it.

During the interview
Amplifying your Effectiveness has an article on how to run interviews when gathering requirements. This is a great article, and one I’ve added to my links at del.icio.us (you should too).

Some key takeaways from their article:

* Use “how” and “what” questions to get to “why” answers - avoiding the knee-jerk defensive reaction.
* Use “tell me more” questions to drill down - “What happens next”, “Can you show me”, etc.
* Use open-ended questions. Yes/no questions are good for validating what you’ve learned already - not for learning new information.
* Don’t bias the results. It’s easy for the interviewer to ask leading questions. We need to realize if there is an implicit premise in the way we ask a question, and if that would bias the results. When we’re first starting out, this meta-perspective is almost impossible, but it becomes second nature over time. If we review our results (recording our questions helps too) after the interview.

Cliche though it may be - a book I’ve read at least a dozen times is How to Win Friends and Influence People by Dale Carnegie.

In that book, he helps us understand that people enjoy talking about what they do. He provides tips and suggestions about how to gain contacts, gather information, maintain relationships, and speak publicly. If you haven’t already read it, it’s in my top two “books that make you better” list. so go read it. One thing that will make you laugh is seeing the dated dollar amounts in many of his anecdotes (the book was written in 1936). My copy was published in 1964, and the pages are starting to get that nice yellowing that comes from great writing.

Carnegie stresses, encourages, and provides techniques for talking to people about what’s important to them, which is directly related to gathering requirements from the beneficiaries of a new system (and the users, who should benefit, but might not if we don’t gather the right requirements).

After the interview
Here’s where many good interviewers drop the ball. This is the time to put a little extra effort in managing our relationships. We should always followup with the interviewee, and let her know “how it went”. We should give her an update on status and let her know which of her great insights is being incorporated into the spec. Anecdotal data is fine, we don’t need to create a laundry list - just an affirmation that her needs are being addressed, and that the time she spent in our interview was valuable. If there’s something that is important to this stakeholder that didn’t make the cut - give her a head’s up.

If we get stuck for a good pretense to having the conversation, we can always use communication of the schedule as an excuse.

These follow-up conversations establish a long term relationship that is good for future releases, helps with change management of rolling out the solution, and establishes or firms up our credibility.

Source: Tyner Blain

2006-07-21T00:56:00.001-07:00

SQL Video Tutorial: Click Here

2006-07-21T00:56:00.000-07:00

Clear Quest: Click Here

2006-07-21T00:55:00.001-07:00

Clear Case: Click Here

2006-07-21T00:55:00.000-07:00

Rational Rose: Click Here

2006-07-21T00:54:00.000-07:00

MS Project Video Tutorial: Click Here

2006-07-21T00:51:00.000-07:00

MS Visio Video Tutorial: Click Here

2006-07-21T00:37:00.000-07:00

Rational Unified Process

The Rational Unified Process (RUP) is a popular iterative software development process created by the Rational Software Corporation, now a division of IBM. The RUP is an extensive refinement of the (generic) Unified Process.

The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. It is intended to be tailored, in the sense that development organizations and software project teams will select the elements of the process that are appropriate for their needs.

The Rational Unified Process (RUP) is also a software process product, originally developed by Rational Software, and now available from IBM. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.

Background

History

The roots of the Rational Process go back to the original spiral model of Barry Boehm. Ken Hartman, one of the key RUP contributors, collaborated with Boehm on research and writing. The Rational Approach was developed at Rational Software in the 1980s and 1990s.

In 1995 Rational Software acquired the Swedish Company Objectory AB. The Rational Unified Process was the result of the merger of the Rational Approach and the Objectory process developed by Objectory founder Ivar Jacobson. The first results of that merger was the Rational Objectory Process, designed to an Objectory-like process, but suitable to wean Objectory users to the Rational Rose tool. When that goal was accomplished, the name was changed. The first version of the Rational Unified Process, version 5.0, was released in 1998. The chief architect was Philippe Kruchten.

Design Objectives

The creators and developers of the process focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.

A representative list of failure causes includes the following:

* Ad hoc requirements management
* Ambiguous and imprecise communication
* Brittle architecture (architecture that does not work properly under stress)
* Overwhelming complexity
* Undetected inconsistencies in requirements, designs, and implementations
* Insufficient testing
* Subjective assessment of project status
* Failure to attack risks
* Uncontrolled change propagation
* Insufficient automation

Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process.

The Process was designed with the same techniques the team used to design software; it has an underlying object-oriented model, using Unified Modeling Language (UML).

Principles and Best Practices

RUP is based on a set of software development principles and best practices, for instance:

1. Develop software iteratively
2. Manage requirements
3. Use component based architecture
4. Visually model software
5. Verify software quality
6. Control changes to software

Develop software iteratively

Given the time it takes to develop large sophisticated software systems it is not possible to define the problem and build the solution in a single step. Requirements will often change throughout a project's development, due to architectural constraints, customer's needs or a greater understanding of the original problem. Iteration allows the project to be successively refined and addresses a project's highest risk items as the highest priority task. Ideally each iteration ends up with an executable release – this helps reduce a project's risk profile, allows greater customer feedback and helps developers stay focused.

The RUP uses iterative and incremental development for the following reasons:

* Integration is done step by step during the development process, limiting it to fewer elements.
* Integration is less complex, making it more cost effective.
* Parts are separately designed and/or implemented and can be easily identified for later reuse.
* Requirement changes are noted and can be accommodated.
* Risks are attacked early in development since each iteration gives the opportunity for more risks to be identified.
* Software architecture is improved by repeated scrutiny.

Using iterations, a project will have one overall phase plan, but multiple iteration plans. Involvement from stakeholders is often encouraged at each milestone. In this manner, milestones serve as a means to obtain stakeholder buy in while providing a constant measure against requirements and organizational readiness for the pending launch.

Manage requirements

Requirements Management in RUP is concerned with meeting the needs of end users by identifying and specifying what they need and identifying when those needs change. Its benefits include the following:

* The correct requirements generate the correct product; the customer's needs are met.
* Necessary features will be included, reducing post-development cost.

RUP suggests that the management of requirements has the following activities:

Analyze the problem is about agreeing on the problem and creating the measures that will prove its value to the organization.

Understand stakeholder needs is about sharing the problem and value with key stakeholders and finding out what their needs are surrounding the solution idea.

Define the system is about creating features from needs and outlining use cases, activities which show nicely the high-level requirements and the overall usage model of the system.

Manage the scope of the system is about modifying the scope of what you will deliver based on results so far and selecting the order in which to attack the use-case flows.

Refine the system definition is about detailing use-case flows with the stakeholders in order to create a detailed Software Requirements Specification (SRS) that can serve as the contract between your team and your client and that can drive design and test activities.

Manage changing requirements is about how to handle incoming requirement changes once the project has begun.

Use component-based architecture

Component-based architecture creates a system that is easily extensible, intuitively understandable and promotes software reuse. A component often relates to a set of objects in object-oriented programming.

Software architecture is increasing in importance as systems are becoming larger and more complex. RUP focuses on producing the basic architecture in early iterations. This architecture then becomes a prototype in the initial development cycle. The architecture evolves with each iteration to become the final system architecture. RUP also asserts design rules and constraints to capture architectural rules. By developing iteratively it is possible to gradually identify components which can then be developed, bought or reused. These components are often assembled within existing infrastructures such as CORBA and COM, or Java EE.

Visually model software

Abstracting your programming from its code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. Using this representation, technical resources can determine how best to implement a given set of inter-related logics. It also builds an intermediary between the business process and actual code through information technology. A model in this context is a visualization and at the same time a simplification of a complex design. RUP specifies which models are necessary and why.

The Unified Modeling Language (UML) can be used for modeling Use-Cases, Class diagrams and other objects. RUP also discusses other ways to build models.
[edit]

Verify software quality

Quality assessment is the most common failing point of all software projects, since it is often an afterthought and sometimes even handled by a different team. RUP assists in planning quality control and assessment by building it into the entire process and involving all members of a team. No worker is specifically assigned to quality; RUP assumed that each member of the team is responsible for quality during the entire process. The process focuses on meeting the expected level of quality and provides test workflows to measure this level.

Control changes to software

In all software projects, change is inevitable. RUP defines methods to control, track and monitor changes. RUP also defines secure workspaces, guaranteeing a software engineer's system will not be affected by changes in another system. This concept ties in heavily with component based architectures.
[edit]

Project Lifecycle
A typical project profile showing the relative sizes of the four phases
A typical project profile showing the relative sizes of the four phases

The Rational Unified Process divides a project into four phases.

* Inception Phase
* Elaboration Phase
* Construction Phase
* Transition Phase

The Inception Phase

In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Requirements understanding as evidenced by the fidelity of the primary use cases.
* Credibility of the cost/schedule estimates, priorities, risks, and development process.
* Depth and breadth of any architectural prototype that was developed.
* Actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.

The Elaboration Phase

The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

This phase must pass the Lifecycle Architecture Milestone by meeting the following criteria:

* A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
* A description of the software architecture in a software system development process.
* An executable architecture that realizes architecturally significant use cases.
* Business case and risk list which are revised.
* A development plan for the overall project.

If the project cannot pass this milestone, there is still time for it to be cancelled or redesigned. After leaving this phase, the project transitions into a high-risk operations where changes are much more difficult and detrimental when made.
[edit]

The Construction Phase

In this phase the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.

This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

The Transition Phase

In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.

If all objectives are met, the Product Release Milestone is reached and the development cycle ends.

Disciplines and Workflows
The Rational Unified Process
The Rational Unified Process

RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved.

The main building blocks, or content elements, are the following:

* Roles (who) – A Role defines a set of related skills, competencies, and responsibilities.
* Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
* Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

The RUP lifecycle has been created by assembling the content elements described above into semi-ordered sequences. Consequently the RUP lifecycle is available as a work breakdown structure, which could be customized to address the specific needs of a project. The RUP lifecycle organizes the tasks into phases and iterations. Within each iteration, the tasks are categorized into nine Disciplines:

Engineering Disciplines:

* Business modeling discipline
* Requirements discipline
* Analysis and design discipline
* Implementation discipline
* Test discipline
* Deployment discipline

Supporting Disciplines:

* Configuration and change management discipline
* Project management discipline
* Environment discipline

Business Modeling Discipline

Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology.

The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers.

Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.

Requirements Discipline

The goal of the Requirements is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, analysts elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions. A Vision document is created, and stakeholder needs are elicited. Actors are identified, representing the users, and any other system that may interact with the system being developed. Use cases are identified, representing the behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to be relevant to the users.

Analysis and Design Discipline

The goal of Analysis and Design is to show how the system will be realized in the implementation phase. You want to build a system that:

* Performs—in a specific implementation environment—the tasks and functions specified in the use-case descriptions.
* Fulfills all its requirements.
* Easy to change if and when its functional requirements change .

Analysis and Design results in a design model and optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written.The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.

Implementation Discipline

The purposes of implementation are:

* To define the organization of the code, in terms of implementation subsystems organized in layers.
* To implement classes and objects in terms of components (source files, binaries, executables, and others).
* To test the developed components as units.
* To integrate the results produced by individual implementers (or teams), into an executable system.

The system is realized through implementation of components. The Rational Unified Process describes how you reuse existing components, or implement new components with well defined responsibility, making the system easier to maintain, and increasing the possibilities to reuse
[edit]

Test Discipline

The purposes of the Test discipline are:

* To verify the interaction between objects.
* To verify the proper integration of all components of the software.
* To verify that all requirements have been correctly implemented.
* To identify and ensure defects are addressed prior to the deployment of the software

The Rational Unified Process proposes an iterative approach, which means that you test throughout the project. This allows you to find defects as early as possible, which radically reduces the cost of fixing the defect. Test are carried out along three quality dimensions reliability, functionality, application performance and system performance. For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution and evaluation.
[edit]

Deployment Discipline

The purpose of deployment is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including:

* Producing external releases of the software
* Packaging the software
* Distributing the software
* Installing the software
* Providing help and assistance to users

Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase.The Deployment and Environment workflows of the Rational Unified Process contain less detail than other workflows.

Configuration and Change Management Discipline

The Change Management discipline in RUP deals with three specific areas:

* Configuration management
* Change request management
* Status and measurement management

Configuration management

Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be placed under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made.

Change request management

During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change.

Status and measurement management

Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest.
[edit]

The IBM Rational Method Composer product

The RUP process framework within IBM Rational Method Composer includes:

* A process content library based on the best practices adopted in thousands of projects worldwide.
* Out-of-the-box delivery processes to provide the project manager with a quick starting point for planning and initiating a project. A delivery process will provide an initial project template, identify what milestones to have in the project, what work products to delivered by each milestone, and what resources are needed for each phase.
* Capability patterns that allow project managers to rapidly add or remove reusable chunks of processes addressing common problems. Since no two projects are alike, project managers need to rapidly modify the process to address the specific project needs.

The IBM Rational Method Composer (RMC) is a commercial product (built on top of Eclipse) for authoring, configuring, viewing, and publishing processes.

RMC has two main purposes:

* RMC is a content management system that provides a common management structure and look and feel for all process content. All content managed in RMC can be published to html and deployed to Web servers for distributed usage.
* RMC provides process engineers and project managers with the capability of selecting, tailoring, and rapidly assembling processes for their concrete development projects. RMC provides catalogs of pre-defined processes (like RUP) for typical project situations that can be adapted to individual needs. It also provides process building blocks called capability patterns that represent best development practices for specific disciplines, technologies, or development styles. These building blocks form a toolkit for quickly assembling processes based on project specific needs. Finally, the documented processes created with RMC can be published and deployed as Web sites. They can also be deployed as project plan templates for IBM Rational Portfolio Manager.

In additional to full RUP, RMC provides RUP plug-ins (extensions to the RUP content that can only be installed on top of RUP) for important areas such as service-oriented architectures (RUP for SOA), systems engineering (RUP for systems engineering), packaged application development (RUP for COTS), program and portfolio management, etc. New delivery processes are added frequently and are made available via the IBM developerWorks Website.

There is an open source version of IBM RMC created as part of the Eclipse Process Framework (EPF) project. The EPF tool contains full process authoring and publishing capabilities. The main difference between EPF and the Rational Method Composer tool is the lack of integrations with other IBM Rational tools such as Rational Portfolio Manager and Rational Software Architect as well as lack of a migration capability from Rational Process Workbench. EPF comes with OpenUP/Basic, a new agile process for small teams applying RUP principles and practices.

Limitations

If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight "out of the box". The IBM Rational Method Composer product has been created to address this limitation and help process engineers and project managers customize the RUP for their project needs. OpenUP/Basic, the lightweight and open source version of RUP, is another attempt to address this limitation.

2006-07-20T23:34:00.000-07:00

Malik Prabu

2006-07-20T23:07:00.000-07:00

Introduction to Business Analysis

Learn How To

• Define the role of the business analyst throughout the phases of a project
• Explain the range of tasks that a business analyst might perform
• Apply principles of quality assurance and testing
• Explain the importance of requirements definition
• Assess the value of use case analysis and design on your work
• Explain how business process, workflow and data modeling techniques facilitate improved communication

Course Synopsis

The business analyst’s role is key to defining the requirements of a project at its earliest stages, as well as to planning, defining and validating project scope. It’s important to have an understanding of the breadth of knowledge that a business analyst brings to bear in developing business solutions.

This introductory course is designed to give people new to the business analyst role or those who supervise and/or work with business analysts a basic understanding of the benefits, functions and impact of this critical position. You’ll experience how a business analyst supports the project, from establishing its scope in the analysis phase to ensuring the requirements have been met in the testing phase. The course provides a special focus on the business analysis function as it relates to developing information technology solutions, given that such an understanding is essential for project –success.

After completing this course, you’ll understand why and when to involve the business analysis function. Plus, you’ll have a working vocabulary to enable you to communicate effectively with those who perform that role. If you are new to the role of the business analyst and need to pursue more in-depth skill development, you’ll leave this course with the framework necessary to support your future efforts.

Course Topics

1. What is Business Analysis?
• IT business analysis
• Business process improvement
• Challenges of gathering and analyzing requirements
• History and current trends in business analysis
• Role of the business analyst through the project life cycle
2. Defining the Business Problem
• Techniques to determine the underlying business problems
• Understanding the business environment at a high-level
• Relating business "problems" and "processes"
3. Root Causes of Problems
• Business problems and root causes
• Applying modeling to understand root causes (the AS-IS state)
o Workflow modeling
o Use Case analysis
o Data modeling
4. Solution Vision and Scope
• Vision and envisioning
• The key players in setting the vision
• How to determine the product scope
• Quantifying process improvement goals
5. Making the Business Case
• How the business analyst adds insight to business cases
• Estimating the benefits associated with the product
6. Modeling the Future State
• Models and modeling
• Relating models to requirements
• Modeling the information requirements (data modeling)
• Modeling the TO-BE state (process and workflow modeling)
7. Getting Requirements from Models
• The value of Use Cases
• Use Case analysis
• Unified Modeling Language (UML) and object-oriented analysis
8. Requirements Definition and Documentation
• SMART requirements
• Identifying the boundary between requirements and specifications
• Managing changes to the –requirements
9. Quality Assurance and Testing
• The business analyst's role in testing
• Quality assurance activities: checking and testing
• Introduction to test strategies and plans

Logical Data and Process Modeling

Learn How To

• Create more accurate and complete requirements
• Use diagramming to communicate project scope
• Create a data model to define and describe project requirements
• Create and use functional decomposition diagrams, entity relationship diagrams and dataflow diagrams
• Use dataflow diagrams to validate data and process models

Course Synopsis

In today’s complex business environment, integration of multiple functional areas combined with fuzzy requirements is a fact of life—a picture is truly worth a thousand words. The techniques used in logical data and process modeling focus on presenting a complete picture of the important requirements of the business (and the related project) through significant user involvement in the analysis phase.

This course provides techniques for effectively analyzing and modeling any area of your business and creating logical data and process models that show how data flows and work progresses. The approaches taught in this class are designed to focus the attention on the important requirements of the business that are discovered through significant user involvement during the analysis phase.

Participants will learn how to create models without being limited by technology or organizational structure. The course exercises are designed to reinforce the techniques taught in class—entity relationship diagramming, functional decomposition diagramming and dataflow diagramming.

Reminder: Prior to taking this course, you should have acquired the background as taught in How to Gather and Document User Requirements.

Course Topics

1. Introduction
• System development challenges
• Benefits of modeling
• Components of logical process models: moving from dataflow to process
• Characteristics of essential modeling
2. Approaches to Functional Decomposition
• Concepts of Perfect Technology
• Top down and bottom up approaches
• Event partitioning
• Using functional decomposition diagrams
3. Introduction to Logical Data Modeling
• Purpose and components
• Data redundancy and derived data
• Different levels of data modeling
4. The Conceptual Data Model
• Discovering entities, attributes and relationships
• Analyzing attributes and choosing unique identifiers
• Relationships and cardinality
5. The Logical Data Model
• Super-types and sub-types
• Attributive and associative entities
• Documenting data constraints
6. Normalization and the Physical Data Model
• The physical data model
• The role of the database designer
7. The Process Diagram in Context
• Purpose and components
• Rules and conventions
• Leveled data flow diagrams
8. Verifying and Presenting Models
• Accuracy and completeness
• Internal verification and external validation
• Effective presentation
9. CASE Tools and Transition to OO/UML
• Major functions of CASE tools
• Introduction to Object Orientation (OO) and Unified Modeling Language (UML)
• Impact of OO/UML on the business analyst

Workflow Modeling

Learn How To

• Create workflow diagrams using various proven techniques
• Determine which workflow modeling technique is best suited for your project
• Find opportunities for process improvement using workflow models
• Validate workflow models to ensure their accuracy and completeness
• Use six proven enablers to improve processes

Course Synopsis

To develop a complete picture of the important requirements to support the business, the next critical step is documenting the flow of work, as it currently exists. Only then can you move forward to design the solution to support the business needs. The workflow model defines and diagrams “how” an organization performs its essential business activities.

The workflow model uses the Logical Process Model as the basis for diagramming each process as a workflow. These diagrams explain each activity and its interactions in detail, including how it is triggered, what resources are needed and what deliverables will be created. This knowledge will enable you to discover and address any unstated requirements prior to finalizing the project plan. These workflow diagrams are key to effective analysis and communications.

Participants will learn how to diagram current operating procedures (AS-IS) and look for areas of improvement (TO-BE). You will be prepared to construct and analyze the workflow diagrams, identify opportunities for process improvements and modify workflow to reflect these new improvements.

Reminder: Prior to taking this course, you should have acquired the background as taught in How to Gather and Document User Requirements and Logical Data and Process Modeling.

Course Topics

1. Introduction to Workflow Modeling
• Concepts of modeling
• Types of models
• AS-IS vs. TO-BE models
• Modeling and the development life cycle
2. Workflow Modeling Basics
• Workflow models
• Relating project deliverables
• Processes, functions and tasks
• Establishing the context of the process
• Identifying the process objectives
3. Workflow Modeling Techniques
• Workflow models and their use
• CASE scenarios
• Workflow diagram components
• Workflow diagramming standards
o ANSI
o IDEF3
o UML
o CASE tools
4. Workflow Modeling Approaches
• Identifying all sources of information
• Necessary levels of detail
• Determining correct approach
5. Analyzing the Models
• Evaluating the value of a business process
• Measure the performance of a business process
• Looking for process improvement opportunities
• Brainstorming techniques
• Creating the TO-BE model from the AS-IS model
6. Verifying and Validating (V&V) the Models
• Sources of information used
• V&V techniques
• Using a walkthrough
• Five questions used to verify models

Use Case Modeling for Business Analysis

Learn How To

• Apply the benefits of use-case analysis throughout your project life cycle
• Describe what use cases can and cannot do for requirements analysis
• Work with end users and use cases to elicit and validate requirements easily
• Define the scope of the system in enough detail to communicate clearly with stakeholders
• Create use-case diagrams, narratives and scenarios
• Utilize use cases beyond the analysis phase

Course Synopsis

It is recognized today that use cases provide a valuable alternative to traditional methods for organizing and describing functional requirements. In particular, use cases allow for more effective communication between the user and technical communities thus helping ensure requirements are universally agreed upon. From the analyst's perspective, use cases are advantageous as they are able to model the entire business process, providing the necessary documentation to identify the system's interactions with the business goals, rules and business-level decisions.

This course frames the process of discovering use cases, beginning with finding the actors, the scope and the various relationships between them. It gives you access to the resourceful nature of the use case by focusing on users' needs and how the system will help satisfy those needs, at the same time providing traceability from requirements to specifications to the product.

You will leave this course prepared to perform the proper tasks to create, document and review use cases to drive systems development. The same discipline can be applied to modeling the business using use cases.
Reminder: Prior to taking this course, you should have acquired the background as taught in Introduction to Business Analysis and How to Gather and Document User Requirements.

Course Topics

1. Use Case Overview
• What is a use case?
• Business use cases vs. system use cases
• Use case approach
• The Unified Modeling Language™ (UML)
2. Use Case Diagrams
• Use case elements
o Actors
o Diagrams
o Scenarios
o Other notations
• Defining project scope
• Dealing with exceptions
3. Discovering Use Cases
• Use cases and actor's goals
• Brainstorming use cases
• Use case granularity
• Defining use cases
• Dealing with commonality
4. Use Case Documentation
• The basics
• Alternate and exception paths
• Other descriptors
o Business rules
o Non-functional requirements
o Extending use cases
5. Completing the Business Analysis
• Use case document review
o Goals of the review
o Common problems and mistakes
• Completing the Business Requirements Document (BRD)
6. Beyond the Analysis Phase
• Use cases and RUP
• Estimating project size
• Test scenarios

Business Object Oriented Modeling

Learn How To

• Apply many concepts of OO as they relate to business analysis
• Use a step-by-step methodology for applying OO modeling techniques to the activities of a project
• Leverage the value of OO and UML techniques by applying them early in a project
• Investigate and document business process and systems behavior using OO and UML
• Eliminate inconsistencies in the business requirements documentation using inheritance, encapsulation and other UML techniques

Course Synopsis

As projects become more and more complex, they continually push the boundaries of the obscure and the unknown. Object orientation (OO) is not just for programming and coding. At a conceptual level, it is changing the way we look at projects by having us view the project, the product or the process in terms of groups of items and processes that have specific properties, called objects. The chief benefits of an object-oriented view are the ability to generalize processes and properties and to identify specific exceptions of the same processes and properties, or what are known as “use cases” and “scenarios,” respectively. This allows for the design of a business process or new IT system today that will allow for the potential for nearly unlimited expansion.

Business Object Oriented Modeling provides the participant with a solid introduction to the language of object-oriented modeling, known as Unified Modeling Language (UML) and a view of this requirements elicitation technique through the eyes of the business analyst, not the systems analyst. UML is very useful in identifying and documenting the current processes (AS-IS) and the future processes (TO-BE), regardless of whether it is for a manual process or an IT solution. It will also help identify what other roles and systems (actors) and processes may change due to the outcome of the project.

This course enables organizations to fully exploit the potential of object-oriented modeling by using it early in the project life cycle when the analysis of the business, the users, and the who and what are involved is being accomplished. Participants in the course will work on a real-world case study to gain practical experience in all of the techniques and tools required to fill the role of the business analyst, whether they are on OO specific projects or looking for a new way of working with the more complex problems of today.

Course Topics

1. Object-Oriented Paradigm Shift
• Benefits of OO modeling using UML
• Application of OO in identifying and documenting business processes
2. Introduction to Object Orientation
• Classes, objects and actors
• Encapsulation
• Attributes and operations
• Aggregation and composition
• Inheritance
• Association
• Polymorphism
• Using cases and scenarios
3. Analyzing the Project
• OO interviewing and stakeholder workshops
• High-level use of case diagrams
• AS-IS process documentation
• Setting the project boundaries
• Grouping the requirements into use cases
4. Dynamic Analysis
• Finding the changes in an object as it moves through the process
• Best practices in describing the process flow, including normal flow, alternate flow and exceptional flow, along with pre- and post-conditions
• Use of decision tables and decision trees
• Documenting Statechart diagrams
5. Static Analysis
• Questions to ask to uncover:
• Entities and classes
• Business process and multiplicity
• Inheritance, aggregation and composition
• Ways to elicit the requirements through brainstorming, interviews, etc.
• Identifying the properties of an object: attributes and operations
6. Completing the Analysis
• The implementation plan
• Baselining for development Handing off for development

Introduction to Testing for Business Analysts

Learn How To

• Create test cases and test scenarios using data, process and workflow models
• Select the right technique to make testing efficient
• Create testing strategies and test plans for high-order testing based on business and user requirements
• Plan and coordinate usability testing
• Conduct reviews and inspections
• Manage problems in a structured way

Course Synopsis

Test plans should not be left for last!

Failure to develop a plan to test the right things at the right time can result in cost overruns, missed completion dates, undetected errors and dissatisfaction among customers and users.

In this course, you’ll learn the necessary skills to construct effective test strategies and test plans to verify and validate requirements—enabling you to deliver the quality your business demands. You will also be able to communicate the rationale for and value of planning and conducting the various necessary reviews and inspections. You’ll gain an understanding of black box and glass box (white box) testing from a business analyst’s perspective—and you’ll know how to communicate with those who perform the systems analyst function..

NOTE: This course focuses on approaches used in IT from the viewpoint of the business analyst. However, the foundations of these techniques are applicable to other disciplines.

Recommendation: Before taking this course, you should have acquired the background as taught in How to Gather and Document User Requirements, Logical Data and Process Modeling and Workflow Modeling.

Course Topics

1. Achieving Quality
• Four underlying principles
• Perceived risk
2. The Role of the BA in Testing
• BA involvement in testing and checking
• V-Model of BA involvement
3. Checking the Business Requirements Document (BRD)
• Four major quality attributes of requirements
• Techniques for checking the BRD
• Peer Review technique
• Eliminating common causes of defects
4. Planning for Assessment and Testing
• Components of the test plan
• Three purposes of testing
• Elements of testing strategies
• Elements of test cases and scenarios
5. Black Box Testing
• Equivalence domain partitioning
• Boundary testing
• Condition coverage
• Decision tables
• Entity relationship diagrams
• CRUD testing (Create, Read, Update, Delete)
• Error guessing
6. Glass Box and Automated Testing
• Activity coverage
• Decision coverage
• Condition coverage
• Automated testing
7. Usability Assessment and Testing
• Usability factors
• Achieving usability
• Usability checklists
8. Writing the Test Plan
• Resource planning
• Time considerations
• Test environment considerations
• Human resources considerations
• Test plan documentation
9. Assessing Customer Satisfaction
• Validating customer needs
• Assessment methods
• Scales of measurement
• Post-implementation planning
10. Acceptance Testing
• Ways to capture informal and formal problems
• Formal acceptance vs. user acceptance testing
• Test Readiness Review

How to Gather and Document User Requirements

Learn How To

• Define the role of the business analyst in the requirements process
• Structure a Business Requirements Document
• Effectively document a project's vision and scope
• Identify user classes and define their environment
• Develop a Requirements Analysis Work Plan
• Define, elicit, structure, validate and document business requirements
• Link the Business Requirements Document to a Software Requirements Specification

Course Synopsis

Incomplete requirements are often cited as the number-one reason projects or systems fail. Accurately defining the requirements and staying on course from the beginning is key to success in today’s business world.

This “how-to” course introduces the roles of the business analyst as they relate to the analysis and documentation of requirements. It familiarizes participants with core knowledge and skills required to analyze and document user requirements. It also identifies how these requirements are defined and managed throughout the life cycle.

Recommendation: The material presented in this course provides the foundation necessary for building additional business analyst skills. You should take this course before taking any additional courses in the curriculum.

Course Topics

1. Roles, Definitions and Key Principles
• Critical role of the business analyst
• Creating and adopting a formal documentation strategy
• Roles and mutual expectations among team members
2. Capturing Requirements in a Business Requirements Document
• Identify critical consumers
• Understand the structure of a Business Requirements Document
3. Project Vision and Scope
• How projects are initiated
• Importance of a project scope statement
• Document project vision and scope
4. Identifying Users and Creating a Work Plan
• Project users and characteristics
• The value of creating a work plan
• The elements in a generic work plan
5. Types of Requirements
• Attributes and types of effective requirements
• What is an effective requirement?
6. Elicitation Techniques
• Apply four different question types
• Advantages and disadvantages of several techniques
7. Structuring End-User Requirements
• Techniques used to structure requirements
• Develop a basic Use Case
• The role of modeling
8. Validating User Requirements
• Requirements validation
• Methods used to validate requirements
9. Documenting User Requirements
• The purpose of documenting requirements
• Apply standard principles and techniques
• Organize your requirements descriptions for communication