Tag: Enterprise

Elements of Requirements Style, Part 3

Written by Karl Wiegers on December 18, 2012. Posted in Articles. 2 Comments on Elements of Requirements Style, Part 3

One of the most common types of requirements problem is missing information. Either entire requirements could be absent—which are hard to spot, being invisible—or individual requirements are missing information that help make them fully comprehensible. In this article, the third in a series of four, I’ll present some examples of both kinds of problems, along with some recommended solutions.

Omissions

When requirements lack important bits of information, it’s hard for all readers to interpret them in the same way unless they make precisely the same assumptions. For instance, a functional requirement might describe a behavior without identifying the triggering cause that leads to that behavior:

The system shall generate an error report and forward it to the user.

This requirement doesn’t identify the stimulus that leads the system to produce the error report. Another common mistake involves missing descriptions of how possible exceptions should be handled. In the previous example, what should happen if no errors occur during the processing being described? It’s unspecified, thereby leaving it up to the developer to decide what to do. Options include:

Do nothing (an assumed default perhaps).
Present a “Congratulations! No errors found.” message but do not generate a report.
Generate an empty report and forward it to the user.
Generate a report stating that no errors were found and forward it to the user.

Perhaps we add the following requirement to address the case in which no errors are encountered:

If parsing is successful, the system shall not generate an error report.

This is another description of the system doing nothing, though, as I discussed under “Negative Requirements” in a earlier article in this series. It would be better to state what the system will do if no error is encountered, even if it is to simply continue the processing.

Another kind of incompleteness occurs when requirements describe system behaviors that involve some type of symmetry. Suppose you’re specifying the functional requirements for a bookmark feature in a Web browser. You might say:

The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.

So, the user can collapse the bookmark tree, but what if he wants to expand it again? It’s easy to overlook that sort of symmetrical or reverse operation. To remedy this, either you could add a second requirement stating that the tree can be expanded, or you could alter this requirement to say “…in a collapsible and expandable hierarchical tree structure.”

If you omit the reverse operation, the customer and the BA might assume that the missing portion of the symmetrical requirement is implied. If you request an undo capability, of course you want a redo capability as well, right? But implicit requirements make me nervous. They involve too many assumptions about the knowledge and thought processes that other stakeholders must have to ensure that we all get what we expect in the final product. I know of a organization that developed its own tool for editing and storing source code in a database, with no written requirements. Unfortunately, they forgot to include the ability to print the contents of the database. The team members no doubt assumed that a printing function would be included so didn’t even think to mention it. They didn’t mention it, and they didn’t get it.

Boundaries

Boundary values in numerical ranges provide additional opportunities for creating ambiguity, as well as being places to look for missing requirements. Suppose you’re writing software for a point-of-sale system and you need to comply with a business rule that states, “Only supervisors may issue cash refunds greater than $50.” An analyst might derive several functional requirements from that business rule, such as the following:

If the amount of the cash refund is less than $50, the system shall open the cash register drawer.
If the amount of the cash refund is more than $50 and the user is a supervisor, the system shall open the cash register drawer. If the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.”

But what if the amount of the cash refund is exactly $50? Is this a third, unspecified case? Or is it one of the two cases already described? If so, which one? Such ambiguity forces the developer either to make his best guess or to track down someone who can answer the question definitively. This is an example of the BA generating an inconsistency between a higher-level piece of information—the business rule—and the functional requirements derived from it.

You can resolve boundary ambiguities in one of two ways. The previous requirement #1 could be rewritten as, “If the amount of the cash refund is less than or equal to $50, the system shall open the cash register drawer.” This preserves the original intent of the business rule and eliminates the ambiguity.

Alternatively, you could use the words inclusive and exclusive to explicitly indicate whether the endpoints of a numerical range are considered to lie within the range or outside the range. To illustrate with a different example, you might say, “The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.” This wording makes it perfectly clear that both endpoints of the range, 6 and 10, lie within the range subject to the 20-percent price discount. You still need to review a set of similar requirements to make sure the range endpoints don’t overlap, though. For example, note the inconsistency between the following two requirements:

The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.
The system shall calculate a 30% discount on orders of 10 to 20 units, inclusive.

The boundary value of 10 is incorrectly included in both ranges. Using a table to show this sort of information is more concise and makes these kinds of errors more evident:

Units Purchased	Discount Percentage
1-5	0
6-10	20
11-20	30
21+	40

The final article in this series on writing high-quality requirements deals with several fiendish sources of requirements ambiguity: synonyms, pronouns, abbreviations, adverbs, and others.

Don’t forget to leave your comments below.

Addressing Information Security in Business Analysis with SABSA

Written by Sergey Korban on April 24, 2012. Posted in Articles. 1 Comment on Addressing Information Security in Business Analysis with SABSA

In this article, I would like to show how the SABSA (Sherwood Applied Business Security Architecture) framework can be applied to address information security as part of business analysis.

In the business analysis domain, information security was not of much interest throughout the last decade or so. However, an incredible rate of development in mobile technology and the penetration of mobile computing into the corporate environment has increased the importance of information security.

This has led me to explore how the SABSA framework can be helpful to a business analyst in addressing the security needs of the business. While I have found quite a lot of value in applying the ITIL framework, I think the SABSA framework aims to fill the gaps in the ITIL framework regarding information security.

The Governance Pyramid

First of all, let’s consider governance. Governance in any business is not a simple set of internal rules. Each business has its own policies and procedures governing the functioning of the business, and they form the bottom layer of the governance pyramid.

Best practices are incorporated to improve the functioning of the business and make it more competitive and sustainable. These practices make up the middle layer of the governance pyramid.

The top layer consists of industry regulation and laws coupled with standards to which businesses have to adhere.

Each of these layers has specific information security requirements. However, they are not consistent across these layers as there is no underlying system that translates multiple requirements into a cohesive set of requirements applicable to a particular business and covering the business objectives.

The SABSA framework serves as a system to ensure that the information security needs of an organisation are thoroughly understood, designed, delivered and well supported along with the IT infrastructure.

The Four Ps

Successfully ensuring information security is not just about using the best hardware and software. It requires a broader view that incorporates the four Ps: People, Processes, Products and Partners.

Internal policies, well-designed processes with a focus on information security, properly configured hardware and software products, and well maintained relationships with partners and suppliers create a coherent set of information security practices within the business.

How SABSA Empowers a Business Analyst

As SABSA is an enterprise security architecture framework, it can be used for the development of business solutions at any level of granularity and complexity.

The value that SABSA creates for business analysis lies in the questions that have to be answered before beginning a solution design. These questions help specify the solution more precisely and avoid costly mistakes and low user satisfaction.

The SABSA model has a layered structure as shown in the diagram above. Each layer provides a set of questions asked from different viewpoints.

The contextual layer guards business analysts from jumping to a conclusion at the start of a project. It gives a business analyst the following information:

business context
business asset taxonomy
business motivation
affected processes
users involved in the processes
location where the solution is required
time when the solution needs to be available.

The common questions to ask here are:

Why does the business want this solution?
What type of solution should be built?
What aspects of business security should be addressed?
How will the solution be used?
What business processes and data require information security?
Who will use the solution (types of users, their mobility and their numbers)?
What credentials should be allocated to users to enable the use of the solution?
Where should the solution be located?
What security measures should be in place to ensure the secure use of the solution?
What are the solution’s relationships with the existing business landscape?
When will the solution be used (usage patterns, critical business days, etc.)?

The conceptual layer is concerned with the selection of logical and physical components that will be used to build the solution later. Here the business analyst learns about:

business risk strategy
control objectives
the process mapping framework
IT architecture strategies
roles and responsibilities of stakeholders (users, service providers).

The questions revolve around the security principles that will be used within the solution, and include the following:

What business information should be protected within the solution?
Why is the protection of the identified information important?
How can the required protection be achieved at the business process level?
Who will be involved in security management during the production use of the solution?
Where should the protection be applied (boundaries)?
When is the protection sufficient (measurement)?

Proceeding downwards, we come to the logical layer. This layer helps the business analyst determine:

the current inventory of IT assets (CMS means Configuration Management System. See ITIL v.3 for more detail)
risk management policies
processes and enabling IT services (service catalogue)
entities and trust models
interaction flows between locations
schedule of events (start time, duration, end time).

In practice, the contextual and logical layers listed above are the most difficult and few businesses are ready to demonstrate what they have in place. The reason for this awkward state is that quite often the IT department does not have a business service catalogue and a supplementary configuration management system detailing all IT assets.

The following questions should be asked at this point:

Why does the specified business data require protection (policies, regulation)?
What business data should be secured?
How should the business data be protected?
Who will be involved in securing the data? What will be their relationships?
Where do the security measures apply (security domains and their boundaries)?
When do the security measures start to apply (deadlines, schedules)?

The logical model ensures that the solution can satisfy the business objectives and are realistic from an engineering perspective.

Once the logical security modåel is understood, it is time to look at the physical layer. The logical model of information security is translated into the physical security mechanisms, and this layer helps the business analyst learn:

the business data dictionary
business data objects
risk management rules and procedures
existing applications, middleware and security mechanisms employed
user interfaces to IT services
access control mechanisms in use
the IT infrastructure (platforms, networks and their layout).

Here the following questions should be asked:

Why should the specific logic be applied (procedures, conditions, rules)?
What security-related data structures (business data models) should be included in the solution scope?
How will the security mechanisms (encryption, access control, digital signatures) be applied?
Who will be affected by the security mechanisms?
Where will the security infrastructure be hosted (locations, layouts, communication links)?
When will the specified security mechanisms be embedded into the processes?

Now let’s have a look at the existing environment and select the elements that will be re-used within the solution.

The component layer focuses on the assembly approach to ensure that all pieces fit nicely together and serve the purpose as expected. The logical and physical layers feed the gathered information into the component layer, which helps the business analyst learn:

the IT products (business applications, servers, repositories)
risk analysis, monitoring, recording and reporting tools
protocols used to enable business processes
user roles, their functions, actions and access permissions.

The questions to ask here are:

What IT components (applications, servers, repositories) are in the solution’s scope?
How will the specified IT components be used?
Who will assemble the components (identities, roles, access control)?
Where will the assembled components be located?
When should the assembly process start?
What is the time schedule for the solution to be assembled?

The final layer is security service management, which is concerned with ongoing maintenance of the solution and the embedded security mechanisms over the production use of the solution.

The answers obtained at this stage will facilitate the handover process at the end of the project. The questions to ask here are:

What service delivery practices will be applied to ensure operational continuity?
Why should these practices be in place (risk assessment, business continuity planning, risk monitoring and reporting)?
How will security-related operations (user security administration, data backups, security monitoring, etc.) be carried out?
Who will be responsible for account provisioning and user support management?
Where will the security service management be executed (locations, sites, buildings)?
When will the solution’s security service management be activated (security-related calendar or timetable)?

Added value to business analysis

When going through the layers discussed above, a business analyst will collaborate with architects, IT management, IT infrastructure practitioners and partners to ensure:

the collected information is accurate and unambiguous
policies and procedures are in place
the existing IT landscape is known to the architects
the existing components will be re-used to minimise solution costs and operational expenses
the organisation’s requirements are translated unambiguously to partners to ensure trustworthy relationships.

Conclusion

The core function of business analysis is to transform business needs into requirements and ensure that a solution carries out its intended purpose. It is often not sufficient to gather the requirements to a solution to satisfy the explicitly stated business need, but it is easy to skip the requirements for business security by incorporating people, business process and data, premises where the business resides, and trustworthy relationships with business partners.

One more challenge in practice is that stakeholders think that technology covers all bases on its own, and it is hard to get buy-in from senior management of an organisation regarding the need for well-established and maintained information security.

The SABSA framework encourages business analysts to ask more questions to make the requirements clear and fully stated. This framework helps business analysts learn more about the organisations where they work and deliver extra value to these organisations.

Don’f forget to leave your comments below.

Enterprise Architecture – It’s All in the Name

Written by Jason Martin on April 24, 2012. Posted in Articles.

If you’ve been practicing enterprise architecture (EA) or any other formal approach to business analysis for any length of time now, you’ve probably noticed a world of “support groups” growing up around the topic. There are many online blogs and focus groups on LinkedIn and other social media outlets. I hope you have taken advantage of these, as they contain a vast resource of information for every practitioner.

Stick to the point

Like many social media sites, there are always the posts that meander from the topic. You’ve all seen these where someone injects a veiled ad for their multilevel marketing endeavour or their favourite political cause. These are irritating but easily dismissed. Perhaps more disconcerting are the posts that sway from the topic to some closely aligned technical skill. Maybe Java code is closely related to XML, but the topic of the group needs to be respected.

A recent post to which I felt compelled to respond questioned the proper “scope” for an enterprise architecture project. Having been around this game for more years than I like to admit, this prompted me to respond and later to write this article. Without noting a year, I’ve been doing analysis since the early days of “structured analysis” and all of the many methods and tools that followed. I’ve seen the use of improved analysis techniques applied in many ways and supported by many tools. This is not to speak of the plethora of creative terms that every author seems compelled to use in describing the same techniques. This may sell books, but it often complicates and confuses the neophytes in the business.

Project Scope

This most recent post looking for the proper “scope” seems to be from one of those new-to-the-practice analysts. Enterprise architecture is exactly that…”enterprise.” The proper scope for an EA project is the enterprise! Anything smaller is just a contributing project within the enterprise and should be shown as a project area within the enterprise architecture. Most projects are at this smaller scale because few of us are privileged to get the proper sponsorship to do truly “enterprise” architecture. Enterprise is a tricky term, and must be carefully defined as part of the project initiation and charter. (You DO have a project charter, don’t you?) This leads to a whole host of questions about sponsorship and the customer of the EA. Hopefully your EA products are used by senior management for strategic planning purposes. At lower levels they may also be used to guide specific projects, but that is a secondary benefit. The EA should reflect the enterprise and therefore its greatest use is in guiding that enterprise’s strategy. It’s an interesting aside that the Project Management Institute’s Project Management Body of Knowledge (PMBOK) goes into great detail to define projects within programs, but there is nary a mention of the term “enterprise.”

Where does it end?

Scope of the enterprise can be difficult to state. First, your sponsor may not have the purview of the entire enterprise. That’s doesn’t mean that your architecture should be limited by your sponsor’s authority. You may not be able to go into complete detail in those areas outside your sponsorship, but you must include them in the architecture. They DO exist, even if only to interface with your enterprise. In some organizations, you may find that your enterprise crosses many difficult boundaries, some of which are politically impossible to cross. An associate once began trying to do an EA for “health care” in the Department of Health & Human Services within the U.S. government. It quickly became obvious that the enterprise involved more than the political limits of the Department. The Department of Defense runs one of the largest health care operations in the world, but it’s beyond the scope of the Department of Health & Human Services. How do you model this? It would be a travesty to ignore the existence of such a huge and somewhat parallel enterprise. But how does one include such an organization into the models when it is completely outside your sponsorship?

The scope of the EA must take into account the true “enterprise” while also respecting the limits of authority within the organizations. The interfaces and redundant data across multiple boundaries of authority must be noted and respected while building models that are useful and representative of the true functional enterprise.

Overall

Scope is always one of the first and most difficult definitions for any project. Certainly trying to model the enterprise makes for some difficult decisions before the work can even start. Don’t fool yourself into claiming a scope that is only part of the true enterprise, even if your authority is limited. Your sponsor’s limitations do not change the facts of what the true enterprise entails. Model the true scope and then carve out projects inside that scope for incremental progress. Each project should plot against the overall enterprise like a mosaic taking shape.

Don’t forget to leave your comments below.

The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

Written by Kathleen B. Hass, PMP on March 5, 2012. Posted in Articles. 1 Comment on The Adaptive Business Analyst – As Complexity Increases, the BA Adapts

The world, she is a’changin’. The Internet has made everyone on the globe hyper-connected and has transformed virtually all industries: publishing, broadcasting, communications, and manufacturing. Did you know that just a few short years ago:

Facebook	Didn’t exist
Twitter	Was a sound
LinkedIn	Was a prison
A Cloud	Was in the sky
An Application	Was something you used to get into college
4G	Was a parking space
Skype	Was a typo [1]

Fast forward to now. Traditional work has been commoditized. Anyone with an idea and a little moxie can use their laptop to set in motion a virtual new entity. You can go to:

Taiwan	For product design
Alibaba in China	For low-cost manufacturing
Amazon.com	For delivery and fulfillment
Craigs List	To do your accounting
Freelance.com	To do your logo [2]

If this isn’t bad enough, the heart and soul of middle class jobs are disappearing in the U.S. Consider this: When Apple began manufacturing the iPhone, the company estimated that it would take nine months to find 8,700 qualified industrial engineers in the U.S. to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. In China, it took 15 days. [3] Result: we lost 200,000 iPhone manufacturing jobs.

Many believe that these and many other traditional jobs are not coming back to the U.S. So, what are the jobs of the future? We probably don’t even know what to call them, but they will definitely require creativity, innovation, invention, and lots of complexity. Even today, many companies in Silicon Valley do quarterly reviews of their key project leaders because they can’t wait to find out they have a poor BA or PM. Many U.S. companies report they can’t find the employees they need. American businesses also report that U.S. workers that are available are too expensive and too poorly educated as compared to workers in India, China, South Korea and many other countries.

What does all this Mean to the Business Analyst?

Employers are looking for critical thinking and an ability to adapt, invent, and reinvent; collaborate, create, and innovate; and an ability to leverage complexity to compete. Standout companies are using projects as the hotbed of creativity – so that means BAs and PMs have to step up their game. According to the 2011 CHAOS Report from The Standish Group, only 37% of projects delivered on time, on budget, with required features and functions.

The Cause: Gaps in enterprise business analysis and complexity management
The Cost: USD 1.22 trillion/year in the US and USD 500 billion/month worldwide in IT project waste
The Opportunity Cost: “If we could solve the problem of IT failure, the US could increase GDP by USD 1 trillion/yr.” according to Roger Sessions, a recognized expert in enterprise architecture and author of Simple Architectures for Complex Enterprises.

We need to fundamentally change the way we do projects so that 80% of projects are on time, budget and scope (see Figure 1). But we also need to focus on innovative solutions, not incremental changes to business as usual. And we need to bring about value to the customer and wealth to the organization – otherwise, why are we investing in the project? This is where the BA comes in – constantly focusing on value and leveraging complexity to foster creativity.

Figure 1: New Project Approach

Does the business analyst role change, either significantly or subtly, with highly complex projects? If so, how? Our framework for dealing with complex projects consists of four distinct activities (see Figure 2):

Diagnose Project Complexity
Assign Competent Leaders
Select the appropriate project management approach
Manage complexity dimensions

This article in the series will examine steps 1 – 3.

Figure 2: Project Complexity Framework

Step #1: Diagnose Project Complexity
The first step in understanding the level of complexity of your project is to assess each complexity dimension. Use the Project Complexity Model depicted in Figure 3. Facilitate your project team leads to agreement on which cells most closely describe your project for each complexity dimension. Then apply the project complexity formula to determine the complexity profile of your project. In my experience, the actual complexity of projects exceeds the team’s initial assessment prior to applying the model.

PROJECT COMPLEXITY MODEL 2.0

Figure 3: Project Complexity Model 2.0
© Kathleen B. Hass and Associates, Inc.

Then apply the formula below, Figure 4 to diagnose the complexity level of your project.

PROJECT COMPLEXITY FORMULA

Figure 4: Project Complexity Formula
© Kathleen B. Hass and Associates, Inc.

Step #2: Assign Competent Project Leaders
Complex projects require seasoned leaders, and the use of a shared leadership model (see Figure 5). The core project leadership team consists of the PM, BA, Chief Architect, Development Lead and a Business Visionary, each taking the lead when a particular expertise is needed.

Figure 5: Shared Leadership Model

Once the project complexity is known, it is imperative that appropriately skilled and experienced individuals are assigned to key leadership positions. Obviously, BAs need more sophisticated skills as they move from low complexity projects, to enterprise, strategic and innovation projects. The first order of business is for the organization to understand their BA Workforce. Check out the blog site: http://baassessmentmatters.blogspot.com/ posting on March 5^th entitled “Calling All BA Practice Leads!” It discusses how BA Practice Leads ensure their organizations have an appropriately skilled BA workforce (see Figure 6) possessing the capabilities needed to successfully deliver complex new business solutions that meet 21^st century business needs.

Figure 6: BA Workforce Capability Model

The BA Manager or Practice Lead then assigns BAs (and working with other managers, assigns other project leaders) based on the complexity profile of the project at hand (Figure 7). If the project leads’ capabilities are lower than the complexity of the project requires, it is almost certain that you will have a challenged and/or failed project.

Figure 7: Make Appropriate Leadership Assignments

Step #3: Select the Project Approach
As projects have become more complex, project cycles have evolved. Project cycles models are not interchangeable; one size does not fit all. Project cycles can be categorized into three broad types:

Linear: used when the business problem, opportunity, and solution are clear, no major changes are expected, and the effort is considered to be routine. A linear cycle is typically used for maintenance, enhancement, and continuous process improvement projects. It is also used for development projects when requirements are well understood and stable, as in shrink-wrap software development projects.
Adaptive: used when the business problem, opportunity, and solution are unclear and the schedule is aggressive. An adaptive cycle is typically used for new technology development, new product development, or complex business transformation projects.
Extreme: used when the business objectives are unclear or the solution is undefined. An extreme cycle is typically used for research and development, new technology, and innovation projects. [4]

Figure 8 shows the differences between linear and more adaptive methods.

Linear Methods	Adaptive Methods
Industrial-age thinking Plan based Distinct life cycle phases Tasks completed in orderly sequence Assumes predictability Lays out development steps Stresses the importance of requirements	Only firm basic requirements that are not expected to change (aka high-level requirements) and a release plan up front Many rapid planning and development cycles Produces small batches of tailored products on a tight schedule Evolution of requirements with each planning and development cycle Constant evaluation of the evolving product Constant evaluation of the value of functions in backlog

Figure 8: Linear vs. Adaptive Methods

As we move along the complexity continuum from independent, low complexity predictable projects to highly complex projects with lots of uncertainty, we also move along the spectrum of project cycle types. A linear approach works for a simple, straightforward project; whereas, adaptive, and extreme approaches are used to manage the uncertainties of increasingly complex efforts (see Figure 9).

Figure 9: Project Complexity Mapped to Project Cycle Approaches
© Kathleen B. Hass and Associates, Inc.

Low-Complexity Projects: Traditional Waterfall Methods
The traditional role of the business analyst does not need to change much to successfully execute activities on low-complexity projects. The linear Waterfall Model is appropriate (see Figure 10). However, to optimize the business analyst role, it is wise to adopt some of the principles of agile and iterative development for even low-complexity endeavors:

Prototype for requirements understanding, to reduce risk, and to prove a concept
Involve the business and keep the business analyst as a member of the core project leadership team throughout the project
Continuously validate, evolve, and improve requirements throughout the project.

Figure 10: The Waterfall Model

Moderately Complex Projects: Agile Methods
There’s no question about it: agile methods expedite the product development process, especially for products that are software intensive. Agile is an adaptive, streamlined model, based on having only essential people work in tight-knit teams for quick and efficient results (see Figure 11). As we’ve seen, one very important member of the team is the business analyst; if companies hope to achieve strategic goals, they need someone who is focused on the business value expected from the project outcomes. The business analyst provides guidance before funds are invested, during a project, and after the solution is delivered. She continually focuses on the evolving business requirements and serves as the steward of the business benefits. [5]

Figure 11: The Agile Model

Through leadership and collaboration, the project manager and business analyst guide the agile team, ensuring that it is both efficiently and effectively run and that it adds significant long-term benefits for the company with each iteration. The business analyst plays close attention to the original business case, recommending the project be terminated when the ROI has been realized.

Firm Basic Requirements
A business analyst’s main priority when she is first attached to a specific project is to elicit firm, basic business requirements (what we used to call high-level requirements, which outline the breadth of requirements and which we do not expect to change), to collaboratively determine the most feasible solution, and then to categorize releases into valuable features and functions. Then each release is initially described in enough detail to determine its cost versus its benefits, thus developing an ROI for each release.

Knowing what it will take to deliver each individual component of the solution as well as what the return will be to the organization, the development team can then build components or features based on business value, delivering the highest-value features first. As the project moves through the release schedule, the business analyst elaborates the requirements in enough detail to meet the development team’s needs for each release.

An Eye on the Business Value
As an agile project progresses through its life cycle, the team continually learns new information. It becomes clearer how many resources will be needed to perform detailed design, construction, and tests for each release, how much risk there is to the project, and how the risk needs to be managed. Accordingly, it is important to go back and check original assumptions about business value and costs to develop and operate the new solution to see if they are still true, or if the original business case has been compromised.

Validation after Every Release
By being involved during the development process, business analysts can validate that new components are actually meeting business needs and that the business case is still sound. They also take information to other groups outside of the agile team to further corroborate that the inevitable changes have the support of other stakeholders.

Organizational Transition Requirements
The operational environment needs to be analyzed and assessed before the solution components are implemented. Perhaps there will be a need for reorganization, retooling, retraining, or acquisition of new staff. Working with management, the business analyst helps to ensure the organization is prepared for the impact of the changes and can support the release plan. That way, when the complete solution is delivered, it can be operated efficiently and effectively.

Lighter Requirements
Agile requirements are typically “lighter” than those developed for linear project models. Requirements are visually documented whenever possible. The wise business analyst uses modeling to manage complexity. Less formal user stories (a high-level description of solution behavior) may suffice, as opposed to use cases.

Advanced Skills
Advanced skill development is required for business analysts who are working on agile projects. They need to develop new or higher-level leadership skills, including expert facilitation, coaching, collaborative decision-making, and team development. The analyst also needs to have a good understanding of software architecture and be proficient in decoupling the breadth of the solution from the depth of the solution into feature-driven requirements.

Highly Complex Projects, Programs, and Megaprojects: Extreme Methods
Welcome a certain amount of complexity and churn because it creates a chemical reaction that jars creative thinking,
—Colleen Young, VP and distinguished analyst and IT adviser, Gartner, Inc.

Highly complex projects offer the greatest opportunities for creativity: complexity breeds creativity. But the business analyst must understand the nature of complexity to leverage complexity to foster innovation. Complexity is one of those words that is difficult to define. Some say complexity is the opposite of simplicity; others say complicated is the opposite of simple, while complex is the opposite of independent.

Since complex projects are by their very nature unpredictable, it is imperative that the project team keep its options open as long as possible, building those options into the project approach. This approach requires that considerable time be dedicated to researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying potential options to meet the business need or solve the business problem. In addition, the team experiments with alternative solutions and analyzes the economic, technical, operational, cultural, and legal feasibility of each option until it becomes clear which solution option has the highest probability of success. When the opportunity is unclear and the solution is unknown, traditional linear approaches simply will not work.

Last-Responsible-Moment Design Decisions
On highly complex projects, it is important to separate design from construction. The key is to use expert resources and allow them to spend enough time experimenting before they make design decisions; the construction activities will thereby become much more predictable. Linear methods might then be appropriate during the construction phase of the project.

Models for adaptive project management are still emerging. We suggest two that are designed to provide iterative learning experiences, adapt and evolve as more is learned, allow analysis and experimentation to determine solution design viability, and delay decision-making as long as possible (that is, until the last responsible moment, the point at which further delays will put the project at risk): the adaptive evolutionary prototyping model and the eXtreme project management model. There are significant differences between the adaptive and eXtreme approaches (see Figure 12).

Adaptive Methods	eXtreme Methods
Many rapid planning and development cycles Produce small batches of tailored products on a tight schedule Constant evaluation of evolving product Constant evaluation of the value of functions in backlog	Keep your options open Build options into the approach Discover, experiment, create, innovate Analyze problem/opportunity Conduct competitive, technical, and benchmark studies Brainstorm to identify all possible solutions Analyze feasibility of each option Design and test multiple solutions

Figure 12: Adaptive vs. Extreme Methods

Evolutionary Prototyping Model
The keep-our-options-open approach often involves rapid prototyping—a fast build of a solution component to prove that an idea is feasible—which is typically used for high-risk components, requirements understanding, or proof of a concept.

Evolutionary prototyping is quite effective for multiple iterations of requirements elicitation, analysis, and solution design. Iteration is the best defense against uncertainty because with each iteration, the technical and business experts examine the prototype and glean more information and certainty about functions that are built into the next iteration.

The strength of prototyping is that customers work closely with the project team, providing feedback on each iteration (see Figure 13). If requirements are unclear and highly volatile, prototyping helps bring the business need into view.

eXtreme Project Management Model
An extreme project is a complex, high-speed, self-correcting venture during which people interact in search of a desirable result under conditions of high uncertainty, high change, and high stress. —Doug DeCarlo, author and lecturer, Extreme Project Management

eXtreme project management is sometimes also called radical project management. Some equate it to scaled-up agile methods. The approach consists of a number of short, experimental iterations designed to determine project goals and identify the most viable solution. As in the agile model, eXtreme project management requires that the customer be involved every step of the way until the solution emerges—a practice that involves many iterations. Like the iterative Spiral Model, the eXtreme model terminates after the solution is found (or when the sponsor is unwilling to fund any more research); the project team then transitions to one of the other appropriate models. One variation of the eXtreme Model spends a considerable amount of time in discovery, then prototypes, then transitions to modular development (see Figure 14).

Challenges will arise at every turn, because it can be difficult to:

Know how long to keep your options open
Build options into the approach without undue cost and time
Gather the right group of experts to discover, experiment, create, innovate, and:
- Analyze the problem/opportunity
- Conduct competitive, technical, and benchmark studies
- Brainstorm to identify all possible solutions
- Analyze the feasibility of each option
- Design and test multiple solutions.

Operating on the Edge of Chaos
Conventional business analysis practices that assume a stable and predictable environment encourage us to develop all the requirements up front, get them approved, and then fiercely control changes. As we have seen, conventional linear project cycles work well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21^st-century projects. Figure 15 compares the characteristics of projects on which conventional linear practices can be successfully used with the characteristics of projects that require a more adaptive model. A blend of the linear, adaptive, and eXtreme models is almost always the answer. The trick is to know when and how to apply which approach.

Conventional linear approaches work well for projects that…	Adaptive approaches work well for projects that…
Are structured, orderly, disciplined	Are spontaneous, disorganized
Rely heavily on plans	Evolve as more information is known
Are predictable, well defined, repeatable	Are surprising, ambiguous, unique, unstable, innovative, creative
Are built in an unwavering environment	Are built in a volatile and chaotic environment
Use proven technologies	Use unproven technologies
Have a realistic schedule	Have an aggressive schedule; there is an urgent need

Figure 15: Conventional vs. Adaptive Approaches

What exactly does it mean to operate on the edge of chaos? Complex systems fluctuate between a static state of equilibrium and an adaptive state of chaos. If a system remains static, it will eventually result in paralysis and death. Whereas, if a complex system is in chaos, it is unable to function. So, here is the genius of complexity: it breeds and nourishes creativity, as complex systems adapt to changes in the environment for survival. Complexity scientists tell us that the most creative and productive state is at the edge of chaos. (Refer to figure 16.) Therefore, complex project teams must operate at the edge of chaos for a time in order to allow the creative process to flourish. The business analyst assigned to a complex project must use adaptive business analysis methods to foster an environment where creativity is possible. The next article in this series explores the business analyst as creative leader of complex projects who are living on the edge.

Figure 16: The Edge of Chaos: the Most Creative State

Putting It All Together: What Does This Mean to the Business Analyst?
A business analyst who is an asset to highly complex projects is comfortable with lots of uncertainty and ambiguity in the early stages of a project. She leads and directs plenty of sessions of brainstorming, alternative analysis, experimentation, prototyping, out-of-the-box thinking, and trial and error, and encourages the team to keep options open until they have identified an innovative solution that will allow the organization to leap ahead of the competition. The BA who does not embrace complexity does so at her own peril.

Kitty is the president of her consulting practice specializing in enterprise business analysis, complex project management, and strategy execution. She is a prominent presenter at industry conferences, author and facilitator. Her BA Assessment Practice is the gold standard in the industry. KHass BA Assessments:

Appraise both BA organizational maturity and individual/workforce BA capability based on four-stage reference models
Present results that are continuously examined for reliability and validity by Lori Lindbergh, PhD, Senior Researcher and Psychometrician , Lorius, llc
Benchmark results against a global data base of BAs performing comparable work
Align with the IIBA BABOK^® and the BA Competency Model^®
Align with standards and best practices for quality and fairness in educational and psychological assessment
Are based on the skills and knowledge needed to work successfully on the complexity of current project assignments
Examine critical relationships between competency, project complexity, and project outcomes.

Don’t forget to leave your comments below.

[1] Tom Friedman, Michael Mandelbaum, That Used to be us: How America Fell Behind in the World it Invented and How we can Come Back, 2011.
[2] Ibid., p. 134.
[3] How the U.S. Lost Out on iPhone Work, The New York Times, January 21, 2012. Online at: http://www.nytimes.com/2012/01/22/business/apple-america-and-a-squeezed-middle-class.html?pagewanted=4&ref=charlesduhigg
[4] Robert K. Wysocki, Effective Project Management: Traditional, Adaptive, Extreme, 4^th ed. (Indianapolis: Wiley Publishing, Inc., 2007), 48.
[5] Kathleen B. Hass, “An Eye for Value: What the Business Analyst Brings to the Agile Team,” Project Management World Today (June 2007), 1-5.

Questions for Eliciting User Requirements

Written by Karl Wiegers on December 6, 2011. Posted in Articles.

The Business Analyst as Explorer, Part 4 of 6 by Karl Wiegers

This article presents several sets of questions the business analyst might consider asking customer representatives during a discussion about user requirements. Don’t use these questions as a script to be followed by rote in an elicitation workshop. Instead, look for ways to build these sorts of questions into the natural flow of a requirements exploration.

What are some reasons why you or your colleagues would use the new product? These “reasons to use” could become candidates for use cases. They might identify business tasks or objectives that members of a particular user class might need to achieve from time to time.

What goals might you have in mind that this product could help you accomplish? Use cases normally are directed toward helping the user achieve a specific goal. The name of the use case indicates the goal the user has in mind: Print a Boarding Pass, Withdraw Cash, Submit an Employment Application, and so on.

What problems do you expect this product to solve for you? Understanding the problems and limitations the users perceive in their current environment helps the BA determine appropriate capabilities for the new system. This question also helps determine whether the end users’ objectives for the system align well with senior management’s objectives, as captured in the business requirements. If not, you need to iterate between the business requirements and user requirements to align expectations.

What external events are associated with the product? BAs sometimes use the term business event to describe the triggering condition that launches execution of a use case. Perhaps a help desk receives a phone call from a user who needs assistance. This external event triggers the help desk staffer to create a problem report ticket. In products such as real-time control systems, use cases aren’t a valuable technique for understanding user requirements. An alternative approach is to identify the external events the system must detect. Then describe the appropriate system response, which depends on the state the system is in at the time each event is detected.

Most requirements discussions focus on functionality. However, a product’s nonfunctional characteristics also have a great impact on how users feel about the product. Questions such as the ones that follow help the BA understand the user’s expectations about aspects of the product’s quality.

What words would you use to describe the product? Consider asking users to close their eyes and describe their vision of the future system. Listen to the words they use to describe the product. Nouns suggest objects the system must be able to manipulate (such as order, reservation, chemical, account balance, sensor). Verbs can indicate actions the user expects to be able to take or expects the system to take (such as place, create, revise, submit, receive, detect, measure, display). Adverbs convey the user’s thoughts about the product’s characteristics (for example, quickly, reliably, efficiently, flexibly, easily).

Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics? You can never create a product that combines the maximum levels of all quality characteristics. Tradeoffs are necessary between properties such as usability and efficiency, integrity and usability, and integrity and interoperability. (See Chapter 12 of my book Software Requirements, 2nd Edition for more about tradeoffs.) Therefore, it’s important to understand which specific portions or aspects of the product have critical quality demands so that developers can optimize their designs to achieve those objectives.

Are there any constraints or rules to which the product must conform? Most products are subject to corporate policies, industry standards, government regulations, and computational algorithms. It’s essential to know about such business rules so the BA can specify functional requirements to enforce or comply with those rules. Look for subject matter experts within the organization who have current knowledge about the business rules.

How is the product you envision similar to the way you do business now? How should it be different? When automating current business processes or replacing an existing information system with a new one, it’s easy to inadvertently re-implement all the shortcomings of the current approaches. This is known as “repaving the cow paths.” It’s difficult for people to break from the mindset of their current ways of working and to envision something that’s really different and better. The BA should stimulate the thinking of the user representatives to rethink business rules and business processes to see what has changed—or what could change.

What aspects of the current product or business process do you want to retain? To replace? Customer acceptance of a new product depends partly on how familiar it feels to them. Similarity to previous products and processes reduces the learning curve, making it easier for users to master a new system and workflow.

The following questions help the BA gain a richer understanding of how potential users view the product. Asking these questions of people who represent different stakeholder groups can reveal conflicts that you’ll need to reconcile.

Which aspects of the product are most critical to creating business value? A user’s view of business value might be different from a manager’s view or an acquiring customer’s view. A user might value a more efficient way to perform a specific task that will save considerable time over many executions. A manager could be more impressed if the product has lower acquisition and support costs than the one it’s replacing.

What aspect of the product will be most valuable to you? Least valuable? No project can deliver everything to everybody on day one. Someone needs to determine the implementation sequence for various capabilities. Ask this question of different user representatives, and look for patterns that indicate certain product capabilities are more important and more urgent than others. Those capabilities should have top priority.

What is most important to you about the product? This deliberately vague question could generate responses dealing either with the product itself or with other aspects of the project. One user might say, “It’s most important that this system be available before the beginning of the next fiscal year.” Another might respond, “It’s most important that this system will let me import all my data from these older systems we’ve been using.” A manager might say, “It’s most important that the people in my department can get up to speed on this new system without training.” These responses have implications for how the project is planned, the functionality to include, and usability, respectively.

How would you judge whether the product is a success? A business manager might judge the success of the product quite differently from how members of various user classes determine success. Surface these different perspectives early so that they can be reconciled to keep all stakeholders working toward a common objective.

Can you describe the environment in which the product will be used? The operating environment has a big impact on both requirements and design decisions. The user interface is also highly sensitive to the operating environment. Touch screen displays are superior to keyboards in some settings, for example, and speech recognition is becoming increasingly effective for certain applications.

The more the BA can learn about how users intend to employ the product, the better she can do at determining and specifying the functionality that developers need to implement. When you get right down to it, users don’t really care about product features; they care about getting their job done efficiently and maybe even enjoyably.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.