Tag: Requirements

Can I have My Requirements and Test Them Too?

Written by Cynthia Low on December 15, 2008. Posted in Articles.

A study by James Martin, An Information Systems Manifesto (ISBN 0134647696) has concluded that 56% of all errors are introduced in the requirements phase and are attributed primarily to poorly written, ambiguous, unclear or missed requirements Requirements-Based Testing (RBT) addresses this issue by validating requirements to clear any ambiguity or identifying gaps. Essentially, under this methodology you initiate test case development before any design or implementation begins.

Requirements-based testing is not a new concept in software engineering – in fact you may know it as requirements driven testing or some other term entirely – and has been indoctrinated in several software engineering methodologies and quality management frameworks. In its basic form, it means to start testing activities early in the life cycle beginning with the requirements and design phase and then integrating them all the way through implementation. The process to combine business users, domain experts, requirements authors and testers; and obtain commitments on validated requirements forms the baseline for all development activities.

The reviewing of test cases by requirements authors and, in some cases, by end users, ensures that you are not only building the right systems (validation) but also building the systems right (verification). As the development process moves along the software development life cycle, the testing activities are then integrated in the design phase. Since the test case restates the requirements in terms of cause and effect, it can be used to validate the design and its capability to meet the requirements. This means any change in requirements, design or test cases must be carefully integrated in the software life cycle.

So what does this mean in terms of your own software development lifecycle or the overarching methodology? Does it mean that you have to throw out your Software Development Life Cycle (SDLC) process and adopt RBT? The answer is no!. RBT is not an SDLC methodology but simply a best practice that can be embedded in any methodology. Whether the requirements are captured as use cases, as in Unified Process, or scenarios/user stories, as in Agile development models, the practice of integrating requirements with testing early on helps in creating requirement artifacts that are clear, unambiguous and testable. This not only benefits the testing organization but the entire project team. However, the implementation of RBT is much cleaner in formal waterfall-based or waterfall derived approaches and can be more challenging in less formal ones such as Agile or Iterative-based models. Even in the most extreme of the Agile approaches, such as XP, constant validation of requirements is mandated in the form of ‘customer’ or ‘voice of the customer’ sitting side-by-side with the developers.

To illustrate this, let us take the case of an iterative development approach where the requirements are sliced and prioritized for implementation in multiple iterations. The high-risk requirements, such as non-functional or architectural requirements, are typically slated in initial iterations. Iterations are like sub-projects within the context of a complete software development project. In order to obtain validated test cases, the team consisting of requirements authors, domain experts and testers cycle through the following three sets of activities.

Validate business objectives, perform ambiguity analysis. Requirement-test case mapping.
Define and formalize requirements and test cases.
Review of test cases by requirements authors and domain experts.

Any feedback or changes are quickly incorporated and requirements are corrected. This process is followed until all requirements and test cases are fully validated.

Simply incorporating core RBT principles into your methodology does not imply that fewer errors will be introduced in the requirements phase. What it will do is catch more errors early on in the development process. You have to supplement any RBT exercise by ensuring you have the means to build integrated and version-controlled requirements and test management repositories. You must also have capabilities to detect, automate and report changes to highly interdependent engineering artifacts. This means proper configuration and change management practices to facilitate timely sharing of this information across teams. For example, if the design changes, the impact of this change must be notified to both the requirements authors and the test teams so that appropriate artifacts are changed and re-validated.

Automating key aspects of RBT also provides the foundation for mining metrics around code and requirements coverage, and can be a leading indicator of the quality of your requirements and test cases. True benefit from the RBT requires a certain level of organizational maturity and automation. The business benefits from having increased software quality and predictable project delivery timelines. Thus, by integrating testing with your requirements and design activities, you can reduce your overall development time and greatly reduce project risk.

Sammy Wahab is an ALM and Process consultant at MKS Inc. helping clients evaluate, automate and optimize application delivery using MKS Integrity. Mr. Wahab has helped organizations with SDLC and ITSM processes and methodologies supporting quality frameworks such as CMMI and ITIL. He has presented Software Process Automation at several industry events including Microsoft Tech-Ed, Java One, PMI, CA-World, SPIN, CIPS, SSTC (DoD). Mr. Wahab has spent over 20 years in technical, consulting and management roles from software developer to Chief Technology Officer with companies including Tenrox, Osellus, American Express, Parsons, Isopia Compro and Iciniti. Mr. Wahab holds a Masters in Business Administration from the University of Western Ontario.

ITIL for BAs. Part V; Service Level Management

Written by Terry Longo on December 15, 2008. Posted in Articles. 1 Comment on ITIL for BAs. Part V; Service Level Management

Our previous post discussed the value of the Service Catalog in representing IT’s general capabilities, expressed in terms of IT Services, described in the language of IT’s customers. To quickly recap:

the Service Catalog represents the current state, and committed-to-future state, of IT’s capabilities,
Service Level Agreements (SLAs) represent the current state of the relationships between IT and its customers in terms of service delivery commitments, and
the Service Catalog Manager is responsible for ensuring the completeness, accuracy, and fitness for purpose of the catalog

The service catalog manager, however, is not responsible for ensuring that the right services are being cataloged – that responsibility belongs to the Service Level Manager, the key liaison between IT and its customers.

It can be easily argued that the service level manager is the IT business Aaalyst. Just as the “business” business analyst is responsible for the entire life cycle of the business requirements and the suitability of overall business solution, so the service level manager is responsible for the entire life cycle of the IT Service requirements and the suitability of the overall IT Service solution as a contribution to the overall business solution.

Note that, as I have proposed numerous times in the past, there is a basic assumption that the overall business solution includes non-IT components as well (internal/external marketing, training, Both the business BA and the IT BA (the service level manager) follow a rigorous life cycle based process of managing requirements, and the distinction is a matter of scope only. The Business Requirements Document (BRD) from the business BA will contain the requirements for the IT service as well as the requirements for the non-IT solution components. The service level manager will run with the IT service requirements (and in fact will have ideally been engaged with the business BA early in the process of developing that BRD, identifying the appropriate solution, and formulating the supporting business case).

From a process point of view, the service level manager and business BA work together through all aspects of the IT service life cycle: strategy, architecture, design, development, release and deployment, operation, continual improvement, and retirement. The types of inputs from the business BA into the service level management process are too numerous to list here but can be generally categorized as

functional requirements
non-functional aka supplemental aka Quality of Service requirements (ITIL’s preferred term), including availability, capacity, continuity, security, and manageability requirements (each of which essentially has a corresponding owner within IT, e.g., Capacity Manager, etc.)
service monitoring, reporting, and reviewing requirements

The parallels between the service level manager as defined by ITIL V3 and the business analyst as defined by the BABOK, and the business BA – service level manager relationship, are significant. For the enterprise grappling with the question as to whether the BA should be hosted by the business or the IT organization seems likely to become fairly settled once an IT organization adopts ITIL. It seems sometimes that the distinction between the two roles becomes clouded by the magnitude of the complexities and risks of the IT components of the business solutions. And indeed those complexities and risks merit a lot of attention!

Does your IT shop practice ITIL V3? Does your enterprise have some form of a BA Center of Excellence? If yes to both, does your enterprise Business Analysis model recognize the Service Level Manager as a “business analyst” with an IT specialty? I hope to see your comments below.

In the meantime, may you and yours have a long, relaxing and love-filled Holiday!

Trends in Business Analysis and Project Management to watch for in 2009

Written by Cynthia Low on December 15, 2008. Posted in Articles.

The close of the year tends to make one reflect on the past and ponder the future. Here we ponder some trends in the business analysis and project management fields for 2009. We invite you to read some of these trends and ponder for yourself our views about what project professionals can do about them.

Convergence of PM and BA Roles. As the economy tightens, organizations will decrease their project budgets. But, they still need projects done, so look for organizations to try and combine the role of the BA and PM on projects. A recent survey on BA Times finds that an equal number of “project professionals” (our term to encompass both project managers and business analysts) feel that the PM and BA role will be combined on many projects in 2009. Project managers will be asked to do more requirements elicitation and analysis. Business analysts will be required to manage more projects. Oh, and by the way – you will need to do that in addition to your normal roles!

What Project Professionals can do about it: If you are a project manager, sharpen your requirements elicitation and analysis skills. If you are a BA, learn how to plan and execute projects better, and to manage risks. The other advice we can give is “Concentrate on the work, not the worker.” No matter what your job title, make sure you know the tasks and outputs expected of you to help achieve project and business success.
Greater Emphasis on Requirements in Project Management. The upcoming 4th edition of the PMBOK® (Project Management Body of Knowledge) is due to be released in 2009. The Project Scope Management Knowledge Area contains a new section 5.1 called “Collect Requirements” that was largely written by us (Elizabeth and Rich). It contains a number of requirements elicitation techniques that project managers should be able to use to elicit requirements for projects. They are a subset of the techniques described in the Business Analysis Body of Knowledge (BABOK®), so BAs also need to be familiar with these. The section places an emphasis on the Requirements Management Plan and use of the Traceability Matrix for managing requirements and product scope.

What Project Professionals can do about it: When the new PMBOK® Guide becomes available, make sure you obtain it and read the section on Collect Requirements. It’s not because we wrote much of it (well, we are proud of it!). Both PMs and BAs should be aware of what this widely-used and referenced guide says about requirements. The PMBOK® has heavily influenced the practice of project management the past several years, and the new edition promises to do the same.
Change in Requirements Approaches. We see a continued trend in business analysis techniques continuing into 2009. Here are some to consider:
1. Slightly less reliance on use cases and movement towards user stories and scenario-based requirements. Use cases will still be used, especially with complex requirements with intricate interfaces or tricky infrastructure considerations.
2. Less emphasis on requirements specifications, more emphasis on modeling, prototypes and diagrams. For many reasons, there is a trend away from only formal written requirements specifications. That doesn’t mean written requirements have no place, but it does mean the industry is using additional methods of documenting requirements.
3. More requirements management. To control scope and fulfill business needs, there will be continued increase in business analysis and requirements planning in 2009. We see more and more organizations using traceability to control and manage product scope. Both the upcoming PMBOK® and current BABOK® feature this technique and emphasize the use of a traceability matrix.

What Project Professionals can do about it: Keep using use cases, but bear in mind there are other good requirements analysis techniques. Supplement your requirements specifications with models to document and help you better analyze requirements. Learn about other methods, such as user stories and use the technique most appropriate for the type of requirement you are analyzing. For example, do data modeling for refining your data requirements.

Increased use of Agile Approach and Techniques. Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue as organizations adopt Agile techniques and the industry adopts commonly accepted practices. Agile itself is evolving to the needs of the industry. For example, the need for more planning has been recognized. For instance, the concept of “Scrum of Scrums” to coordinate Agile teams has surfaced. Another trend we’ve noticed is Agile teams incorporating traditional techniques like requirements workshops and more documentation.

What Project Professionals can do about it: Like any new approach, make sure you learn the generally accepted practices, not just the way a consultant or a single “expert” advises. There are many self-proclaimed experts out there, and some shortcuts on planning and requirements are being taken and justified by being called “agile.”
BABOK® continuing to have an impact. The practice of business analysis is being positively influenced by the Business Analysis Body of Knowledge (BABOK®). The BABOK® Knowledge Areas of Enterprise Analysis are beginning to gel in organizations, as is the need to do requirements planning. We’re seeing more formality and standardization in the methods, say, of doing business cases, or using traceability to manage requirements.

Also, the various elicitation techniques in the BABOK® area are being more widely adopted. Interviews and requirements workshops are common forms of elicitation, but we feel the BABOK is influencing BAs to use additional techniques such as prototyping and interface analysis and to include them in their requirements planning.

What Project Professionals can do about it: Download the BABOK® from the IIBA and start reviewing it. Use it as an input to recommending business analysis standards in your organization. Being some of the firsts CBAPs (Certified Business Analysis Professionals), we believe in and urge others to pursue certification in business analysis. It helps promote the profession of business analysis in general and helps you to solidify and integrate the tools and techniques in the BABOK®, and to “personalize” them to your organization.
Business Intelligence Continues to Grow. This area of information systems has been growing steadily and 2009 promises to have no letup. As BI tools and techniques improve and solid benefits are realized, organizations will invest more and more in this tactic. Since BI relies heavily on tools such as Business Objects or Cognos, the underlying business requirements can be easily overlooked in favor of what the tools can produce.

What Project Professionals can do about it: Learn how to identify how BI can help your business perform better. BI applications should be actionable and project professionals should focus on true business requirements instead of particular tools. Learning to ask the right questions is key, and anticipating how clients will use their data, although challenging, is well worth the effort.
“The Economy, Stupid,” as a past political slogan said. A slumping economy tends to affect travel and training budgets, and this one is no exception. That translates into fewer trips to national conferences or travel to out-of-state training classes.

What Project Professionals can do about it: Attend local conferences that you can drive to. Many local chapters of PMI and now IIBA are launching Professional Development Days or PDDs. Watch for announcements to these and plan to attend. If you have a conference such as Project Summit/Business Analyst World in your town, take advantage of the opportunity and you will find excellent speakers and workshops there. Have you noticed the big increase in webinars as a way of exchanging information and interacting virtually without travelling? Watch for more of the same in 2009. We plan to offer regular webinars throughout 2009.

Interestingly, national conferences like the PMI Global Congress North America attracted many foreign workers this year, from expanding economies such as Brazil and Russia. These growing countries will have larger travel budgets than some of their US counterparts. We also see continued rising international interest in PMI and IIBA.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

The Importance of Business Domain Modelling

Written by Suzanne Jane Maxted on November 3, 2008. Posted in Articles. 1 Comment on The Importance of Business Domain Modelling

As human beings we created language and learned to classify objects in the world around us so that we could share concepts and ideas. Then we learned to write … and we haven’t yet learned when to stop! Often, repeated refinement of our customer’s problem and need statements are seen as measures of quality and completeness of requirements. It’s almost as if the greater the weight of the document the higher the quality!

The purpose of business modelling, and of our role as business analysts, is to describe the business and its intentions. According to The Unified Modeling Language (UML) User Guide, “a model is a simplification of a complex reality … so that we can better understand …” A model allows us to find meaning in the business domain and to communicate an understanding effectively to others. It helps the business owners to visualise together with us, and to specify their intentions in a disciplined and rigorous way. It is difficult for the business to manage what they cannot see. In a model, existing concepts and new requirements can be seen logically related to each other.

The beauty and uniqueness of a business is usually found in its business process and most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) diagram of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

The (simplified) use case summary diagram depicts the proposed use of the system for the trader. To specify our requirements, we have developed the business process and the use cases in a model. Is there more to do? Can we assume that any audience of this view will understand the concepts referred to – the ingredients of the business process recipe? This article proposes that a critical part of requirements elicitation is to understand and provide a static or structural view of the business domain.

We may ask “What is the point of business domain modelling?” The point is that we need to understand the things that we are referring to in the business process and use cases. Remembering that human beings need to ‘classify’ objects around them in order to understand the world and to communicate an understanding, we use the concept of a “class” to sketch the important things that exist for our customer. It is a view of what we need to understand and reach agreement about.

It is the view that gives us the truth – it communicates the things that are true no matter how we behave, no matter what time of day it is and no matter where we are in the business process. In this example, we need to answer the questions: What is a “certificate”? Can a “trader” apply for more than one? What does a certificate certify?

For readers not familiar with the UML, the food export business domain model, in the form of a class diagram tells us that a Trade is an aggregation of a set of Commodity Goods Items. An Export is the type of Trade relevant to this piece of work, along with the CAP Export type Certificate.

In this example, if we do not understand the important concept of a certificate and how it relates to a “trade”, the proposed software may not capture the critical business rules to prevent the trader’s potential loss of thousands, even millions of tax refund. Seeing these two concepts, and the business rules that associate them, pictorially, in a formal standard notation, makes it easy for us to ask the right questions and for the business to see whether the description of their business and of their need is correct. Consider the impact of not understanding the ingredients of the business process recipe.

Only the important detail has been captured for the food export requirements, i.e. that one or more Certificates can authorise a single Trade and a single Certificate can authorise one or more Trades. This is important because if a Certificate is not fully ‘used’, the tax refund for the unused part cannot be claimed by the Trader.

It took many questions to understand this because some traders matched their certificates one-to-one with their trades; some traders had lost certificates, some had let certificates expire, some had checked that government regulation would allow them to use up portions of certificates to authorise a trade. It would have been difficult to find those questions had I not drawn what the traders were saying and instead, simply had written down verbatim what they thought they wanted based on their problems. Modelling the requirements was an easy way to resolve any contradictions and to capture the most important business rules to provide real benefit to the trader.

It is important to model the business domain or as my favourite writer on the UML, Martin Fowler says, the “logic that is the real point of the system”.

The alternative is to write a similar amount of text as found in this paragraph for each “requirement” and lose the advantage of adding to the model. In addition, the process of documenting, reviewing and refining this text would cost a great deal more than asking our business customers to sign the whiteboard with the confidence that the domain model / use cases (i.e. requirements) covered on it have been captured correctly.

So often errors are found in traditional requirement documents after sign-off because so many statements were made, unrelated to each other, where no logic could be applied to associate them. Another reason for so many errors could be that the requirements i.e. a very long list of textual requirement statements, are never read – they are so very boring and time-consuming to review.

I once reviewed a high-level requirements specification comprising 300 pages of textual requirement statements. I counted 321 instances of the word “customer” and 656 written instances of a few other major business classes. I counted nearly 7000 instances of eight common words such as “to”, “the”, and “system” – words of no value or interest. I wonder how many more words of the total 38000 were unnecessary and meaningless, and that required time to be written, read, refined and read again by numerous people up and down stream of the author.

In a requirements model, these few words of real interest would be written a few times only. In a business domain model, or class diagram, expressing those requirements in relation to each other, it would be necessary to write each word once only as the name of a class (while in a workshop with our business customers of course). If the business architecture was already established in the organisation, then it would be necessary to simply reference them, rather than re-invent them (again!); one would simply familiarise oneself with the area of interest and then visualise the proposed change together with the business owners.

Business domain modelling can be applied to any concept.

Modelling and communicating business concepts in a standard notation keeps it easy for our customers … our service remains consistent and audiences beyond the here and now can understand and reuse our work. When I draw a purple triangle, I know what it means. You, the reader, do not. However, if you or I were to draw the following simple class diagram, every single business analyst and solution architect in the world, even the occasional project manager, should be able to understand it.

I am currently working in a project team with English speaking Russians – there is no language barrier when we show them our model drawn in our common language – the UML. The UML modelling notation, for the purposes of describing business, commonly uses about 15 simple symbols which can be nonchalantly explained to subject matter experts during a workshop session without burdening them with any lengthy training. My experience of appropriately exposing the UML to my customers has been, without exception, very positive.

Modelling or graphical notations were invented to precisely convey a concept and to depict a great deal of information in a concise way, rather like electrical circuit diagrams or architectural drawings. Their other purpose is to act as precise shorthand for what we verbalise and know to be true. Would it be natural for an electrician to write “the electrical system must allow the electrical current to flow into a capacitor which must discharge into a resistor”? A simple line drawing with universally understood meaning and without ambiguity suffices to say the same thing. Its advantage is that further requirements will be part of the same drawing and any defects or conflicts can be spotted easily in relation to the other elements on the diagram. In addition, should any changes to the implemented electrical system be necessary later, the model could be reused by other people to understand the current system and the impact of the proposed changes. That is impossible with hefty volumes of prose.

Business modelling is much more fun than writing a requirements novel that few people have time to read. I call on project managers and business analysts to dispense with their document weighing scales and embrace clear, correct and effective communication of ideas and business concepts.

In a future article, we will look at modelling the business actors and areas of interest in order to express the current business problem and to propose the goodness or scope of a project i.e. setting the scene or business context ready for further analysis.

This article is based on one of the “Truth, Beauty & Goodness” series of presentations named “The Importance of Business Domain Modelling” given by the author at the Business Analysis World Symposium 2008 held in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: Lawson Davies, Brent Lewis and John McPherson.

Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years information systems experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children.

Nearly Painless UML

Written by Cynthia Low on October 15, 2008. Posted in Articles. 1 Comment on Nearly Painless UML

UML (Uniform Modeling Language) is a significant technical advance in the ability to formally specify, visualize and document existing and envisioned improvements to business processes and systems. UML was established by the collaborative efforts of three software engineering leaders each of whom had his own formalized methodology: Grady Booch, James Rumbaugh, and Ivar Jacobson.

They were able to create a common set of formalized concepts, diagramming conventions and methods to foster clear and efficient communications that are effective for both traditional and the modern needs for object-oriented programs, database systems, and web-based applications. UML has since evolved into an industry standard for software engineering best practices that is supported by tools such as Microsoft Visio and others.

While UML concepts have had much potential for improved communication of existing processes and business requirements with business management and staff, their potential is often difficult to realize in implementation.

Conventional wisdom suggests a multi-day UML class to train the key business users in UML similar to that done successfully for technical staffs. However, motivating and training already busy executives, business management and staff in a “cram UML course” often is overwhelming and ineffective plus it can easily instill a pervasive negative attitude toward UML and the requirements definition processes due to its perceived complexity and actual rigor.

The “Painless” UML Alternative
Business Analysts that have attained a good understanding and command of UML can identify current business processes and issues as well as communicate a vision for business improvements using UML. By using some extra imagination and ingenuity they can create effective diagrams, charts, ROI analysis and functional specifications to communicate meaningful business concepts in UML that can be easily understood by business management, functional-area staff and technical staff without mentioning UML.

These specifications and presentations can often be based on UML concepts, diagrams and methods without subjecting the business community to the rigors and “Pain” of formal UML training. The primary goal of the Business Analyst and their Business Clients is to establish effective communication – the particulars of what type of arrow is used in which diagram is only important when all are trained to use the same exact conventions or when communicating with UML-Trained and practicing technical staff.

In many organizations, UML is often not of interest and not a priority for executives, managers and non-technical staffs – nor must it be. In the author’s experience, effective UML and non-UML diagrams can be used to communicate efficiently to subtly begin introducing advanced UML concepts such as object-oriented inheritance, use-cases, functional swim-lanes and business process flows as ways to better understand and communicate business concepts. In this way, such advanced concepts are efficiently introduced and learned gradually in a more natural way, as discussed below.

In many cases the innovative Business Analyst can consolidate a big picture of how the business is supposed to work, actually works or should work better into a single picture that is “worth a thousand words” to clarify, communicate and help make the right business and/or technical decisions (as illustrated in the example below).

The concepts communicated in high-level diagrams, such as shown above, can be further decomposed into functional components and detailed specifications that are easily understood by technical and non-technical staff alike. Because staff members are already familiar with their business, they can now better see the complete picture and readily grasp new and advanced concepts such as inheritance (IS-A Relations) in the diagrams.

The staffing for the warehouse is clearly depicted in the object-oriented UML inheritance diagram (on the right) that shows the different roles assumed by warehouse workers.

Likewise, the same approach can be applied to define other types of objects such as products or equipment to clearly specify the general types and subtypes.

The functional vision for a proposed system can be introduced at a high level (as shown below) and then subsequently shown in more detail as the functional design approach is further detailed.

The functional design for a system as it affects different departments and functional organizations as well as the primary input and output information sources are shown in the example below,

The three separate vertical areas are called “Swimlanes” in UML. The diagram above clearly shows the functionality and high-level process flow among: Sales Automation, Production Management and Dispatch & Routing whether you know UML or not.

As business processes are defined at additional levels of detail, “Use Cases” are a very effective way to identify business objects and the business operations that must be supported in the application for those objects as shown in the example below.

Use Case diagrams provide additional detail by showing which operations may be performed by each type of worker that was defined in the prior inheritance diagram.

Use Case diagrams also employ inheritance relationships that are easy to understand by both technical and non-technical staff.

The clarity provided by these diagrams and methods allow functional users to catch omissions and mistakes such as: allowing the packing and shipping tasks, but forgetting that you must also provide tasks to accept and process returns as a part of project reviews and discussions.

Use Case diagrams are especially important to object-oriented software development projects since they typically become a guide as to how the objects and programs are designed and structured.

As the business analyst continues to understand the new manual and automated processes that will be integrated, a new functional organization for the many different warehouses begins to emerge as a diagram that aids in efficient discussion, review and innovation by the functional, technical and management staff involved (as shown in the diagram below).

These examples are just a few ways a business analyst’s skill at understanding and creating effective pictures of your current process and the vision for your improved manual and automated business processes can be evolved methodically as a progressive series of steps.

Clear and effective communication of business facts and needs serves to get both technical and non-technical staff on the same page as well as leads to better project results.

In Summary
This “Painless UML” case study has supplied examples as to how UML and even sophisticated concepts can be gradually introduced and discussed with business staff in a natural way by presenting their own business requirements and processes in a understandable format and making the extra effort to ensure that staff comprehends it.

The full UML (Unified Modeling Language) is quite extensive and many of its features, diagrams and nuances are primarily of concern to the technical staff – “Under the Hood”, so to speak, in the mechanic’s and engineer’s world. Similarly, you only need to understand a car’s controls to drive it just as only a portion of the UML is needed for effective Business Analyst to Business Staff communication in the requirements definition and review processes.

The Business Analyst is the key to effective application of “Nearly Painless UML” for excellence in specifications for the technical community plus keeping the business community focus on effectiveness in the communication, review and gathering of business requirements information without mention of UML.

Byron Claghorn is Director of Corporate Development for Point North Consulting. In this role he is able to leverage his broad experience to both develop and support the various Point North Consulting practices and our service offerings. He has had a long and varied computer science, engineering R&D and consulting career with Burroughs and Unisys Corporation, Vice President of Engineering and Manufacturing for Microcard Technologies and as an Air Force data-automation officer. Much of his career has been focused upon the development of software products and application development tools, client-specific integration of document imaging technology with existing computerized applications, databases and host systems. Byron can be reached at [email protected] or 407-514-2651