ITIL for BAs. Part VI; “Non-functional Requirements”

Written by Terry Longo on January 6, 2009. Posted in Articles.

The two most recent posts about ITIL for BAs emphasized the roles of the IT Service, the Service Catalog, Service Level Management, and the Service Owner in encapsulating IT as a Service Provider.

It would be natural at this point to explore the ITIL/BA relationship from the Service life cycle point of view. Much of both Service Strategy and Service Design address what are typically referred to as non-functional or supplemental requirements. ITIL refers to them as Quality of Service (QoS) requirements.

Other BAs have rightfully pointed out (here is a good example) that QoS requirements frequently do not get the attention they deserve. There are a number of contributing factors:

Stakeholders in QoS requirements are generally not the same as the functional requirements stakeholders
The negotiations involved in QoS requirements and functional requirements are different:
- Functional requirements are normally negotiated by reconciling scope, schedule, and cost factors with development/test/release resources.
- QoS requirements need to be negotiated by reconciling quality characteristics (availability, capacity, continuity, etc.) with IT infrastructure capabilities (assets), constraints (architecture), and even policy (especially in the area of information security management)
Elicitation techniques such as brainstorming, focus groups, interface identification, prototyping, requirements workshops, and reverse engineering are primarily used for functional requirements elicitation.
QoS requirements traceability is evasive; it’s one matter to trace the relationship between a function point in a software library to a step in a business process; it’s quite another matter to trace, say, the specific capacity characteristics of a particular IT component to the variety of business demands relying on that capacity.

It is also interesting to note that the BABOK addresses non-functional requirements most fully in Requirements Analysis rather than in Elicitation.

ITIL’s coverage of QoS requirements is explicit, robust, and effective at contributing to deep business/IT integration. This is evident particularly in the processes defined (Demand Management, Capacity Management, etc.), the extent to which those processes are embedded in the early stages of the IT Service life cycle, and the way in which ITIL defines “utility” (what the IT Service can do) and “warranty” (how well it does it) and then relates utility and warranty directly to their role in business strategy. In my next post, we’ll cover that in more detail and then move into specific QoS-related processes and roles.

If you have any good stories to share about your BA experiences and the challenges around QoS requirements, please share them – your comments are great food for thought for your fellow BAs.

Meanwhile, Happy New Year to you and yours!

Fed-Gov Learning Management

Written by Jonathan Malkin on January 6, 2009. Posted in Articles.

Business analysts are masters at adaptation and learning. A BA can be dropped into any situation and quickly learn everything necessary to get the job done. A business analyst must quickly become a subject matter expert in his or her domain.

Learning Management Systems (LMS) for U.S. Federal Government clients is the domain I currently serve. My first task in entering this position was to identify the key knowledge areas unique to this domain and become an expert in them. This month I explain the key LMS concepts for Federal Government clients: EHRI and SF-182.

“Enterprise Human Resources Integration (EHRI) is one of five OPM led e-Government initiatives designed to leverage the benefits of information technology”, http://www.opm.gov/egov/e-gov/EHRI/.

EHRI requires that federal agencies report all training data on federal employees to (Office of Personnel Management (OPM). This gives OPM, Congress and the President ready access to training data across all federal agencies. Training records are maintained across agencies so if an employee moves from Department of Labor (DOL) to Department of Homeland Security (DHS) their training is ultimately reported to the same repository.

Training data is organized in two major categories: Internal and External.

Internal Training

Internal training is training delivered by an agency to its employees. Typically this training takes place on-site and does not require travel accommodations or other travel expenses. Internal training includes instructor-led and online courses. Internal training typically does not require a provisioning process to allocate money to pay for training and travel.

External Training

External training is training delivered by an external vendor. External training typically requires provisioning money to pay for the course and for travel and accommodations. External training includes instructor-led courses, conferences, and workshops. To facilitate the provisioning process the federal government requires an SF-182 form submitted by the employee.

The SF-182 is submitted through an approval process that most likely includes the employee’s supervisor and the finance or budget department. The employee attends training then validates the actual expenses, course dates, and attendance.

Conclusion

EHRI is a major initiative in the Federal Government to create an electronic record for every government employee. Each employee may be tracked independent of agency assignment. There are many technical challenges in integrating this data that will take several years to resolve. I look forward to a day when federal employees may track their career including training throughout their government service.

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