Articles Archives - Page 402 of 425 - Business Analyst Articles, Webinars, Templates, Jobs

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/.

Stories from the Front!

Written by Marcos Ferrer on December 15, 2008. Posted in Articles.

We are STILL receiving REAL news from BAs and CBAPs at the front lines. Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

I spent about six months refusing a Connecticut based Enterprise Architecture-based job. This was all related to my BA resume and CBAP certification. Recruiters simply wouldn’t go away, though my on-line profile and response was always clear – “not going to Connecticut”.

In the meantime, I got a few direct phone calls, from hiring managers – a little more fun than recruiters – and landed a contract to assist a government agency implement some BA BOK based standards. For me, this is a dream job, a chance to help create an environment where BA is supported (even championed?).

After four months, things are going pretty well – executive involvement is way up, and stakeholders are eager to move to next steps.

The backing is all due to IIBA, the BA BOK, and the CBAP, vendor neutral certification. As always, I am just one more voice in the project, it is the BA BOK that speaks surprisingly loudly, and surprisingly effectively.

Story 2

Not much has changed for me – I have been in a stable, and respected and supported position for several years.

AND we did have some hairy debates concerning data vs. business data vs. data modeling and who had influence and responsibility – my use of the BOK helped settle the matter more quickly and easily.

Story 3

I was engaged by a government agency to introduce BA standards and practices. They worked with me for over nine months, and loved my work, BUT finally told me that they just weren’t ready to make such big changes.

After consulting BOK I realized that I had allowed myself to work on a TO BE, without insisting on eliciting an AS IS. Next time I will not miss this, and will be able to tailor BOK to the actual situation, instead of the ideal one.

De du, de du, de du…that’s all folks!

Keep sending me your war stories!

————————————————————————————–

NEXT MONTH: YOUR STORY HERE or I will be forced to tell mine!

Thanks to my gentle readers for their frankness and willingness to share.

More shall be revealed. Have fun!

The Business Context Model; As Good as it Gets

Written by Suzanne Jane Maxted on December 1, 2008. Posted in Articles. 2 Comments on The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family. I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 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: LD, BL, JM, HT.

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 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. Suzanne can be reached at [email protected] or [email protected]